When configuring ISE pxGrid Identity Mapping (ISE 2.0 naming)/PassiveID (ISE 2.1 naming) integration with Active Directory, there are certain audit settings and permissions that need to be set in order to allow the security audit logs to be read by ISE. If you've ever configured Cisco Context Directory Agent, you're about to receive a blast from the past. This is because the settings and permissions are exactly the same. The Cisco ISE configuration guide even references the CDA documentation when talking about the permissions needed for ISE to communicate for PassiveID. The use case for this is if you're utilizing EasyConnect which is a way for ISE to detect Active Directory successful authentications and grant access based on that. While this may be ideal as a main policy for smaller environments, I think it might also serve as a great default policy for some larger environments instead of a a default rule of "Deny All" depending on the strictness of the security policy.
If you would like to review the full CDA documented requirements, feel free to browse here:
http://www.cisco.com/c/en/us/td/docs/security/ibf/cda_10/Install_Config_guide/cda10/cda_install.html
I'll go through the requirements in order to set up PassiveID between your ISE server and Active Directory:
- Make sure that you have network connectivity between your AD and ISE servers and the ports referenced in the above config guide are open if there is a firewall or software firewall in the way
- If you are using Server 2008 instead of Server 2012 like I am in my lab, make sure that the patches referenced in the CDA documentation are installed
- Make sure that the GPO's Audit policy is correctly configured - I will be going through that in this blog post so continue reading :)
- Make sure that the user you are using to establish the connection between the ISE server and the AD Controller has sufficient permissions. There are different requirements for a Domain Admin and a non-Domain Admin and you will have to make some changes to ensure both work. It's obviously easier to do it with a Domain Admin account since regular Domain User account require a lot of changes but in certain environments that have very tight RBAC requirements, it might be necessary to keep that separate of duties and have a service account for PassiveID integration. I will be using my Administrator account for my lab but I'll go over the requirements for both Domain Admins and non-Domain Admins:
- For members of the Domain Admins, you will need to ownership of the following registry keys and give your domain admin account Full Control of the following keys:
HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}
HKLM\Software\Classes\Wow6432Node\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}
Pretty easy for Domain Admin account.
- For non-members of the Domain Admins group, you will need to do the following:
- Have a Domain Admin give the user account Full Control Permissions of the following registry keys:
HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}
HKLM\Software\Classes\Wow6432Node\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}
- The user must have permission to use the DCOM on the domain controller.
- The admin can run the dcomcnfg tool from the CLI.
- Expand Component Services
- Expand Computers and click on My Computer
- Select Action from the menu bar, click on properties and click on COM Security
- Make sure the user account has Allow permissions for Access and Launch. The user account should be added to all four options (Edit Limits and Edit Default for both Access Permissions and Launch and Activation Permissions)
- Allow all Local and Remote access for both Access Permissions and Launch and Activation permissions
- User account needs to have permissions to the WMI Root\CIMv2 name space.
- Go to Start>Run and type wmimgmt.msc
- Right-click WMC Control and click Properties
- Under the Security tab, expand Root and choose CIMV2
- Click Security
- Add the user account and give the required permissions of Allow for Execute Methods, Enable Account and Remote Enable
- Access to Read the Security Event Log of the AD Domain controller - This can be done by adding the user to the Event Log Readers group in AD.
- For regular domain users to be used, certain registry keys need to be added manually to establish a valid connection between CDA and domain controllers to retrieve the users login authentication events. You can copy the following into a text file, rename it with .reg extension and double-click it to make the registry changes:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
"AppID"="{76A64158-CB41-11D1-8B02-00600806D9B6}"
[HKEY_CLASSES_ROOT\AppID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
"DllSurrogate"=" "
[HKEY_CLASSES_ROOT\Wow6432Node\AppID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
The owner of the keys must be the user account. Also, make sure that you include two spaces in the value of the key "DllSurrogate." Keep the empty line at the end of the script above
"DllSurrogate"=" "
- Have a Domain Admin give the user account Full Control Permissions of the following registry keys:
- The Active Directory user used by PassiveID can be authenticated either with NTLMv1 or NTLMv2. You can verify this or manually set it in your GPO.
- For members of the Domain Admins, you will need to ownership of the following registry keys and give your domain admin account Full Control of the following keys:
If you still have your GPO open at this point, we're go ahead and make the following changes to ensure that the Audit policy is correctly logging everything we'll want for PassiveID Identity Mapping. Change the following settings on your GPO:
Computer Configuration>Windows Settings>Security Settings> Local Policies>Audit Policies> Audit Account logon events: Check Define and Success
Computer Configuration>Windows Settings>Security Settings> Local Policies>Audit Policies>Audit Logon Events: Check Define and Success
Computer Configuration>Windows Settings>Security Settings>Advanced Audit Policy Configuration>Audit Policies>Account Logon>Audit Kerberos Authentication Service:Check Define and Success
Computer Configuration>Windows Settings>Security Settings>Advanced Audit Policy Configuration>Audit Policies>Account Logon>Audit Kerberos Service Ticket Operations:Check Define and Success
Computer Configuration>Windows Settings>Security Settings>Local Policies>Security Options> Network Security:LAN Manager authentication level: Define and Send NTLM response only
After making those changes, close the domain policy. On the Group Policy Management window, right-click the policy you just created and choose Enforced
Open the command line on the server and issue the gpupdate /force command
Go to the Start menu and type regedit to open the registry. There you can take ownership of the following keys and give your Administrator account Full Control over them:
HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}
HKLM\Software\Classes\Wow6432Node\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}
One thing to note: You should take ownership of these keys on every Active Directory server that users will be logging in with.
That's about all you have to do for a Domain Admin account prior to setting it up over on ISE which that configuration will be covered in later posts.