Security

Working thru setting clear pass up with some AP/controllers. Domain controllers are 2008 R2 with one 2003 AD DC to be upgraded. Domain is still 2003 mixed.

 

Pointing at a DC (2K8) I get this error "Ldap error server requires binds to turn on integrity checking" but seems to work pointing at a 2003 AD DC.

 

Under GPO / Comp Conf / Wind Settings / Security Settings / Security Options  I see the following setting:

 

Network Security: LDAP client sigining requirements  not defined

 

Am I going down the right track here? Thoughts?

droidboy,

 

We need more information.

 

Are you doing 802.1x, or pure LDAP?  Are you doing 802.1x for authentication then LDAP for authorization?  Which screeen in ClearPass are you configuring?

 

 

 

Clear Path Policy Manager

 

Configuration » Authentication » Sources » Add

 

AD over SSL Port 636

 

Add cred/password

Add domain

Add base DN

Remove the SSL requirement as well as CA checking to see if it works..

sorry this was for 802.1x, will try the change

Sorry you mean "Enable to verify Server Certificate for secure connection "?

SO LDAP 389 with no cert checking still fails

So when you are at the AD settings and you click on search base DN does it error out there or just when a user auths with .1x?

Are you using a password with a special character?

2013-09-05 16:13:35,201  [Th 7 Req 501 SessId R0000004d-01-522804ef] ERROR RadiusServer.Radius - rlm_ldap: user@here.local bind to 192.168.11.89:636 failed: Can't contact LDAP server
2013-09-05 16:13:35,201  [Th 7 Req 501 SessId R0000004d-01-522804ef] ERROR RadiusServer.Radius - rlm_ldap: (re)connection attempt failed

 

Laptop set up with 802.1x PEAP logs shows.....

 

 

"user auths with .1x?" fails drills down ok in Active Directory

so when you go to Configuration » Authentication » Sources and click on the Search Base Dn link what does it show?

Allows me to drill down to base OU or further with out issue

 

ie ou=users,ou=location,dc=domain,dc=local

[Local User Repository] - localhost: User not found.
domainname.local - 192.168.1.89:636: user_name@domainname.local bind failed - Can't contact LDAP server
EAP-PEAP: fatal alert by client - unknown_ca

---

@droidboy wrote:

[Local User Repository] - localhost: User not found.
domainname.local - 192.168.1.89:636: user_name@domainname.local bind failed - Can't contact LDAP server
EAP-PEAP: fatal alert by client - unknown_ca

---

First off did you join the domain???

 

Administration » Server Manager » Server Configuration click on the server and then click join domain

 

 

 

 

So the last section "EAP-PEAP: fatal alert by client - unknown_ca" Means the client doesnt trust the server cert. 

 

When you log in are you using the full email address or just the username. 

 

Try another account and see if you get the same results or try the same name you 

 

It looks like by the error you are authenticating by the full email address. In your service go to the authentication tab and checkmark the bottom and try striping the username.

 

Thanks for the assistance.

 

Confirming it is jointo the domain

 

Added "Enable to specify a comma-separated list of rules to strip username prefixes or suffixes " as suggested

 

Still not working with the LDAP server 636

 

 

To get LDAP over SSL working on port 636, make sure that the root CA and any intermediate CA certificates are in the CPPM trust list (if the LDAP server certificate was issued by a CA), or add the LDAP server certificate directly to the CPPM trust list (if it is a self-signed certificate).

 

Right cert is installed correctly

 

ANTNZ.local - 192.133.31.89:636: arubatest@domainame.local bind failed - Can't contact LDAP server [Local User Repository] - localhost: User not found. MSCHAP: Authentication failed EAP-MSCHAPv2: User authentication failure

 

 

Still have bind issues.....

 

2013-09-09 12:31:51,199 [Th 2 Req 9 SessId R00000001-01-522d16f7] INFO RadiusServer.Radius - rlm_service: Starting Service Categorization - 252:190:0024D7DD3730 2013-09-09 12:31:51,202 [RequestHandler-1-0x7f7591b15700 r=auto-4 h=79 r=R00000001-01-522d16f7] INFO Core.ServiceReqHandler - Service classification result = Name 802.1X Wireless 2013-09-09 12:31:51,203 [Th 2 Req 9 SessId R00000001-01-522d16f7] INFO RadiusServer.Radius - rlm_service: The request has been categorized into service "Name 802.1X Wireless" 2013-09-09 12:31:51,203 [Th 2 Req 9 SessId R00000001-01-522d16f7] INFO RadiusServer.Radius - rlm_ldap: searching for user Name\arubatest in AD:192.168.1.100 2013-09-09 12:31:51,206 [Th 2 Req 9 SessId R00000001-01-522d16f7] ERROR RadiusServer.Radius - rlm_ldap: arubatest@domain.local bind to 192.133.31.89:636 failed: Can't contact LDAP server 2013-09-09 12:31:51,206 [Th 2 Req 9 SessId R00000001-01-522d16f7] ERROR RadiusServer.Radius - rlm_ldap: (re)connection attempt failed

> bind to 192.133.31.89:636 failed: Can't contact LDAP server 

 

This is strongly suggestive of a network connectivity issue - check for firewalls that might be getting in the way?  You should also be able to verify the connectivity by using Microsoft's Event Viewer.

Installed Softtera LDAP reader andI can confirm I can browse 389 and 636.

 

If I set to 389 I now can auth and log a device in via wireless.

 

I can not if 636 is used.

 

CA Cert Root is installed correclty.

 

Can drill down in the source DN option ok on 389 and 636 ports.

Do you have "Enable to verify Server Certificate for secure connection" checked for that auth source? If so, does it work when it is unchecked?

See the attached file for DN drill down

 

 

---

@avidal wrote:

Do you have "Enable to verify Server Certificate for secure connection" checked for that auth source? If so, does it work when it is unchecked?

---

Neither work....

 

Confirming 389 connections allows a BYOD device to connect just fails when I try secure on 636. BYOD have the Root CA cert installed as well making not difference.

 

External LDAP reader can on another server read the AD DC LDAP on 636 ok.

If you have verified that all certificates in the chain for the certificate being presented by the domain controller are imported into the trusted certificates section within CPPM and enabled and it still does not work, I recommend opening a TAC case.