Good news - bad news regarding CSACS and AD integration

[Travis Hysuick]

Hi all, just a quick note I wanted to point out for any of the AAA admin folks currently using Active Directory for their external identity store.

I'd like to preface this post by saying that I strongly recommend that you purchase the SAS option for your CSACS deployments in addition to the usual SmartNet coverage (I'm a customer, not a sales partner so this is just an IMHO statement).

To get to the meat of the post, the intention here is to provide some information to those of you looking at migrating to a Windows Server 2012 AD environment. Most of you will likely run your AD domains / forests at the Server 2008 functional level unless you're a real bleeding edge shop, however, as it pertains to CSACS 5.x, there are some caveats:

1. Currently (as of Patch 7), CSACS 5.3 does not operate correctly when attempting to attach to and authenticate users in an AD 2012 functional domain/forest. The appliance IS able to generate a computer object account for itself, but it is not able to successfully enumerate any groups or authenticate users (unless I was doing something terribly wrong). At this time, I'm not aware of any intentions by Cisco to support this operational mode, as the documentation clearly indicates that AD versions only up to 2008 are currently supported.

2. Currently, (as of inital release) CSACS 5.4 does integrate correctly with a native 2012 functional level domain/forest, although not strictly mentioned as a supported platform in the product documentation. If you currently running CSACS 5.3, and are considering or planning for an upgrade to Server 2012-based AD in the near future, it may be worth a call to TAC or your SE to find out what the roadmap is for AD 2012 support on ACS 5.3. I don't advocate running out and installing the latest version by any stretch, but I have tested a significant number of scenarios and features (including things like RADIUS pwd change) and 5.4 performs in exactly the same fashion as 5.3, however in very complex environments (of which mine is not), your mileage may vary.

I'd like to hear from any of you that have performed 5.x to 5.4 upgrades and any issues or experiences (either positive or negative), as I have 6 appliances in my deployment that I will be looking at upgrading in the near future. Thanks in advance!

[jmaletzky]

Hi Travis,

in our environment our domain is at Server 2008 functional level  with Windows Server 2008 R2,

CISCO ACS was at Version 5.3 and authenticated users per PEAP with MSCHAPv2 correctly.

We updated our DCs to Windows Server 2012, but kept our Domain at Server 2008 functional level.

Now ACS 5.3 didn't authenticate users per PEAP with MSCHAPv2 anymore. After

updateing to ACS 5.4 no change.

Is there any trick to PEAP working with ACS 5.4 and Windows  Server 2012?

Thanks in advance

Joerg Maletzky

[Tarik Admani]

Joerg,

Can you try turning up an instance of windows 2008 and try using sites and services so that dns queries for you domain only return this server (or groups of servers) to ACS. I dont know exactly what changed in the operating systems when it comes to encryption and kerberos but I would suggest doing this.

Also you can follow the document that i have posted here on further troubleshooting to see what the issue is when the authentication request fails.

https://supportforums.cisco.com/docs/DOC-26787

Also have you tried to reboot the ACS? When you go to the ACS Active Directory settings does it show currently joined? Also when you issue a show application status acs, what is the status of the adclient?

You may try to run this through TAC to see if there is an easy fix but as far as support you may be out of luck:

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.4/device_support/sdt54.html#wp71115

Tarik Admani
*Please rate helpful posts*

[jmaletzky]

Thanks for answering Tarik.

ACS authenticates not PEAP-based login successfully, i.e.:

Nov  6 12:33:07 secsrv adclient[13904]: DIAG  <31 capiauthvalidateplaintextuser=""> audit User 'sk1038' authenticated based on Kerberos exchange to AD

but doesn't authenticate PEAP-based logins, i.e.:

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> base.adagent Domain Level for 'UNI-ROSTOCK.DE' is not PreW2K8

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> base.adagent Domain Level for 'uni-rostock.de' is not PreW2K8

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> smb.util.kerberos Confidentiality=enabled; Integrity checking=enabled

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> com.centrify.smb.smbtree SMB treeConnect to

\\nt1.uni-rostock.de\IPC$

using service IPC.

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> smb.rpc.rpcsec NewRpcSec: type=10 domain=RECHENZENTRUM host=SECSRV sessKey=0xb1e4a660 server= ccachename=

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> smb.rpc.rpcsec RpcSecNtlm::initBindContext: m_bindState=0

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> smb.rpc.rpcsec RpcSecNtlm::initBindContext: m_bindState=1

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> util.except (cims::SMB) : Window Errors (status=0x10002) Debugger continued (reference ../smb/client/smbobject.cpp:325 rc: 65538)

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> com.centrify.smb.smbclient SMB abort connect

\\nt1.uni-rostock.de\IPC$

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> network.state NST:reportFailure: nt1.uni-rostock.de

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> smb.rpc.rpcwrap ExceptionToWinCode: 0x10002

Nov  6 13:12:33 secsrv adclient[6432]: DIAG  <54 ms-rpc="" user="" authentication=""> smb.rpc.rpcwrap Netlogon secure channel failed: (dcName=nt1.uni-rostock.de) (ntStatus=0x10002)

Nov  6 13:12:33 secsrv adclient[6432]: DEBUG <54 ms-rpc="" user="" authentication=""> util.except (cims::RPC) : Get Netlogon Secure Channel failed: Debugger continued (reference ../smb/rpcclient/rpcwrap.cpp:180 rc: 65538)

Nov  6 13:12:33 secsrv adclient[6432]: DIAG  <54 ms-rpc="" user="" authentication=""> daemon.ipclient1 O:netLogonSamLogon - user=nm023 (ntStatus=0xc0000001)

Nov  6 13:12:33 secsrv rt_daemon[5794]: DEBUG lrpc.session O:LRPC::netLogonSamLogon - user=nm023 (rc=9) (ntStatus=0x10002)

Attached you find a debug log.

Greetings

Joerg

[wireless wlc]

hi Jeorg,

  Did you manage to get ACS5.4 working with AD2012 ? I believe the 5.4.0.46.2 cumulative patch will help to make it work ? Please confirm if this worked.

thanks

Joe

[jrabinow]

I can confirm that patch 2 of ACS 5.4 includes support for Windows 2012. Am working to get some additional information included in the read me and release notes. Would be interested to get feedback

[timsilverline]

I just upgraded our ACS system to the latest patch level as I ran into this same problem today after we upgraded our last domain controller to 2012.

After applying the patch I needed to do a full reboot of the system before all of the services would come up but once they did it started working with PEAP again.

[tsteeves]

Thanks to Travis for starting this post and all the great suggestions by other posters.

Our site was running AD 2008 with 2012 schemas. We authenticate wireless and VPN clients against AD via ACS 5.4.0.46.0.

AD was upgraded to 2012 in 2008 functionality mode. Wireless EAP authentications began failing, VPN still worked.

ACS logs showed: Failed Authentication Reason 24444 Active Directory operation has failed because of an unspecified error in the ACS

After much consternation we found this post. Installled 5.4.0.46.2 cumulative patch and wireless authentications started working properly again. Our server guy indicated there may be a different kerberos encryption method in AD 2012 (AES?). Not sure.

Thanks again for the very valuable info.