This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
I have configured ISE Admin Access authentication to a LDAP External Identity Store. BIND Tests to Primary and Secondary LDAP Server is successful. I have configured the major/top domain (DC=test,DC=company,DC=com) ) to see if a user id is found but is not. When I do the same BIND test (same service account credentials) using "ldp" utility in Windows 7 I can find the users under the Base DN Container as well as absolute path (
OU=Users,OU=TestDept,OU=TestEnv,DC=test,DC=company,DC=com) to the actual DN container.
Directory Organization Configuration on ISE:
Subject SearchBase DN: OU=Users,OU=TestDept,OU=TestEnv,DC=test,DC=company,DC=com
Group Search Base DN: DC=test,DC=company,DC=com
Error noticed on ISE Debug Log is:
Server,24/02/2014,08:13:38:869,WARN ,1225325456,cntx=0056723840,user=TESTUSER,LdapSubjectSearchAssistant::checkForErrors: subject TESTUSER is not found,LdapSubjectSearchAssistant.cpp:158
When tested on a Windows machine
c:\>dsquery user -name TESTUSER
Am I missing something here?
Thanks a lot in advance.
Apparently the WLC can do it fine with Local EAP:
PEAPv0/MSCHAPv2 are also supported but only if the LDAP server is set up to return a clear-text password.
Found the problem.
After analysing various packet captures, I noticed that ISE is placing a userPrincipalName LDAP search query for the UserID provided during Logon. When I simulated the same LDAP query using LDP utility on Windows 7, it didn't give me any results however, it did if the filter was for sAMAccountName or CN. I checked the userPrincipalName values in our Domain Controller and found that we are using <userid>@<domainname> format. I then tried to login using <userid>@<domainmain>, it worked.
Note that we do have Groups and Attribute options in LDAP Identity store but those values don't come into action unless userPrincipalName search is successful. Also, I noticed that Groups and Attributes are mainly used for Authentication Policies and to reach that point/step, we first have to get a success response for"userPrincipalName" search.
I have submitted a TAC case to see if there is any way I can place a sAMAccountName search query instead of userPrincipalName LDAP filter.
Under General Tab-> Use Custom Schema instead of AD Identity Source. Once you select Custom, define the ObjectClass, LDAP Search Filter etc and Thats it!
- BTW - I got this answer from TAC. :)
Hi I do have a similar problem.
I try to use LDAP to Access AD for admin authentication.
Could you please specify the working parameters?
Subject Objectclass: <AD Default=Person>
Subject Name Attribute: <AD Default=UserPrincipalName>
Group Objectclass: <AD Default=Group>
Group Map Attribute: <AD Default=memberOf>
I changed to Custom with Parameters:
Subject Objectclass: <User>
Subject Name Attribute: <sAMAccountName>
Group Objectclass: <Group>
Group Map Attribute: <memberOf>