Security

Just to help you reduce complexity during troubleshooting it can be useful to setup an EAP-TLS service as a test to get that working prior to moving to TEAP.

Do. you have an authorisation source that will actually work with the identity in the certificate? This might be why you are having to uncheck Authorization. If the identity doesn't match what is in your source/identity store then no match will be made.

I do have a seperate service that only uses EAP-TLS that works once I'm logged in.

I've used that one and verified that I could authorize both the user and computer.

It doesn't use the same Authentication source but the one for the TEAP service has a copy of it in which we've changed the filter query to include the Method 1 for the Machine and Method 2 for the user.

Just to help you reduce complexity during troubleshooting it can be useful to setup an EAP-TLS service as a test to get that working prior to moving to TEAP.

Do. you have an authorisation source that will actually work with the identity in the certificate? This might be why you are having to uncheck Authorization. If the identity doesn't match what is in your source/identity store then no match will be made.

The messages that you see in the Alerts tab indicate that the username lookup in your Authentication source did not succeed.

Most times that has to do with that the lookup you do does not query the right field in your authentication source. For example, the default AD query uses the sAMAccountname field in AD, which has the 'plain username'. If you switch to EAP-TLS, it typically uses the User Principle Name (UPN) or E-mail, and those are different fields to look up the authentication attributes.

If EAP-TLS works, but TEAP doesn't, then you may either have a different LDAP Query, or you use the wrong fields from your authentication or certificate. If you temporarily disable authorization, from there check the Authentication Source lookups and fix those, This video explains a bit what's going on... it's is slightly different context but related.

I do have a seperate service that only uses EAP-TLS that works once I'm logged in.

I've used that one and verified that I could authorize both the user and computer.

It doesn't use the same Authentication source but the one for the TEAP service has a copy of it in which we've changed the filter query to include the Method 1 for the Machine and Method 2 for the user.

Just to help you reduce complexity during troubleshooting it can be useful to setup an EAP-TLS service as a test to get that working prior to moving to TEAP.

Do. you have an authorisation source that will actually work with the identity in the certificate? This might be why you are having to uncheck Authorization. If the identity doesn't match what is in your source/identity store then no match will be made.

I did as you suggested and disable the authorization and then connected to the SSID with TEAP successfully and in Access Tracker the the username for that session is displayed as myusername@mydomain.se which corresponds to the userPrincipalName in my AD.

With that said I then don't quite understand how the matching of the attributes work.

On my Authentication Source for the TEAP service the filter query for Authentication is currently set as:

(&(userPrincipalName=%{Authentication:TEAP-Method-2-Username})(objectClass=user))

If I then in the same window go to the Attributes tab and do a lookup with myusername@mydomain.se I get a hit and it displays my user account.

It's been a long day and I feel like I'm rambling a bit at this point, but I really don't understand how the matching works.

Do one of these have to match with myusername@mydomain.se or did I missunderstand what you said in your video ?

The messages that you see in the Alerts tab indicate that the username lookup in your Authentication source did not succeed.

Most times that has to do with that the lookup you do does not query the right field in your authentication source. For example, the default AD query uses the sAMAccountname field in AD, which has the 'plain username'. If you switch to EAP-TLS, it typically uses the User Principle Name (UPN) or E-mail, and those are different fields to look up the authentication attributes.

If EAP-TLS works, but TEAP doesn't, then you may either have a different LDAP Query, or you use the wrong fields from your authentication or certificate. If you temporarily disable authorization, from there check the Authentication Source lookups and fix those, This video explains a bit what's going on... it's is slightly different context but related.

I do have a seperate service that only uses EAP-TLS that works once I'm logged in.

I've used that one and verified that I could authorize both the user and computer.

It doesn't use the same Authentication source but the one for the TEAP service has a copy of it in which we've changed the filter query to include the Method 1 for the Machine and Method 2 for the user.

Just to help you reduce complexity during troubleshooting it can be useful to setup an EAP-TLS service as a test to get that working prior to moving to TEAP.

Do. you have an authorisation source that will actually work with the identity in the certificate? This might be why you are having to uncheck Authorization. If the identity doesn't match what is in your source/identity store then no match will be made.

The table that you show at the bottom is the attributes that are pulled from AD, with Name being the name of the attribute in AD and the Alias Name is how the attribute shows up in ClearPass... for the first line, the distinguishedName attribute's value in AD will be shown as UserDN in ClearPass... You could add here extra (non-standard/custom) attributes that you would like to pull from AD...

The Query will instruct AD to return a specific LDAP object (and it's attributes that are mapped according to the table just discussed). In the case of your Query, AD will search for an object that has the objectClass = user, and where the userPrincipleName matches the TEAP-Method-2 username (check in Access Tracker which that is). So no, your UPN would not need to match any attribute in the table.

I did as you suggested and disable the authorization and then connected to the SSID with TEAP successfully and in Access Tracker the the username for that session is displayed as myusername@mydomain.se which corresponds to the userPrincipalName in my AD.

With that said I then don't quite understand how the matching of the attributes work.

On my Authentication Source for the TEAP service the filter query for Authentication is currently set as:

(&(userPrincipalName=%{Authentication:TEAP-Method-2-Username})(objectClass=user))

If I then in the same window go to the Attributes tab and do a lookup with myusername@mydomain.se I get a hit and it displays my user account.

It's been a long day and I feel like I'm rambling a bit at this point, but I really don't understand how the matching works.

Do one of these have to match with myusername@mydomain.se or did I missunderstand what you said in your video ?

The messages that you see in the Alerts tab indicate that the username lookup in your Authentication source did not succeed.

Most times that has to do with that the lookup you do does not query the right field in your authentication source. For example, the default AD query uses the sAMAccountname field in AD, which has the 'plain username'. If you switch to EAP-TLS, it typically uses the User Principle Name (UPN) or E-mail, and those are different fields to look up the authentication attributes.

If EAP-TLS works, but TEAP doesn't, then you may either have a different LDAP Query, or you use the wrong fields from your authentication or certificate. If you temporarily disable authorization, from there check the Authentication Source lookups and fix those, This video explains a bit what's going on... it's is slightly different context but related.

I do have a seperate service that only uses EAP-TLS that works once I'm logged in.

I've used that one and verified that I could authorize both the user and computer.

It doesn't use the same Authentication source but the one for the TEAP service has a copy of it in which we've changed the filter query to include the Method 1 for the Machine and Method 2 for the user.

Just to help you reduce complexity during troubleshooting it can be useful to setup an EAP-TLS service as a test to get that working prior to moving to TEAP.

Do. you have an authorisation source that will actually work with the identity in the certificate? This might be why you are having to uncheck Authorization. If the identity doesn't match what is in your source/identity store then no match will be made.

In that case I'm stumped ...

Both the UPN and what's shown in accesstracker under Method2 matches word for word so I don't understand why I would get an error that says "user not found".

Error Code:    216
Error Category:    Authentication failure
Error Message:    User authentication failed

eap-teap: Method 2 failed for transaction
TEAP_<mydomain>_AD - ad01.<mydomain>.se: User not found.
EAP-TLS: Authentication failure, unknown user
eap-teap: User authentication failed
TEAP_<mydomain>_AD - ad01.<mydomain>.se: User not found.
EAP-TLS: Authentication failure, unknown user
eap-teap: User authentication failed

The table that you show at the bottom is the attributes that are pulled from AD, with Name being the name of the attribute in AD and the Alias Name is how the attribute shows up in ClearPass... for the first line, the distinguishedName attribute's value in AD will be shown as UserDN in ClearPass... You could add here extra (non-standard/custom) attributes that you would like to pull from AD...

The Query will instruct AD to return a specific LDAP object (and it's attributes that are mapped according to the table just discussed). In the case of your Query, AD will search for an object that has the objectClass = user, and where the userPrincipleName matches the TEAP-Method-2 username (check in Access Tracker which that is). So no, your UPN would not need to match any attribute in the table.

I did as you suggested and disable the authorization and then connected to the SSID with TEAP successfully and in Access Tracker the the username for that session is displayed as myusername@mydomain.se which corresponds to the userPrincipalName in my AD.

With that said I then don't quite understand how the matching of the attributes work.

On my Authentication Source for the TEAP service the filter query for Authentication is currently set as:

(&(userPrincipalName=%{Authentication:TEAP-Method-2-Username})(objectClass=user))

If I then in the same window go to the Attributes tab and do a lookup with myusername@mydomain.se I get a hit and it displays my user account.

It's been a long day and I feel like I'm rambling a bit at this point, but I really don't understand how the matching works.

Do one of these have to match with myusername@mydomain.se or did I missunderstand what you said in your video ?

The messages that you see in the Alerts tab indicate that the username lookup in your Authentication source did not succeed.

Most times that has to do with that the lookup you do does not query the right field in your authentication source. For example, the default AD query uses the sAMAccountname field in AD, which has the 'plain username'. If you switch to EAP-TLS, it typically uses the User Principle Name (UPN) or E-mail, and those are different fields to look up the authentication attributes.

If EAP-TLS works, but TEAP doesn't, then you may either have a different LDAP Query, or you use the wrong fields from your authentication or certificate. If you temporarily disable authorization, from there check the Authentication Source lookups and fix those, This video explains a bit what's going on... it's is slightly different context but related.

I do have a seperate service that only uses EAP-TLS that works once I'm logged in.

I've used that one and verified that I could authorize both the user and computer.

It doesn't use the same Authentication source but the one for the TEAP service has a copy of it in which we've changed the filter query to include the Method 1 for the Machine and Method 2 for the user.

Just to help you reduce complexity during troubleshooting it can be useful to setup an EAP-TLS service as a test to get that working prior to moving to TEAP.

Do. you have an authorisation source that will actually work with the identity in the certificate? This might be why you are having to uncheck Authorization. If the identity doesn't match what is in your source/identity store then no match will be made.

I've been looking at som logs in accesstracker and found something odd that I figured I ask here.

In the log for one of my other services that only uses EAP-TLS I can see how it finds my username in the attribute "Authentication:Username" and then adds that to the ldap serch string:

DEBUG RadiusServer.Radius - modcall: entering group svc_TYR 802.1X Wireless_3005 for request 1154
DEBUG RadiusServer.Radius - modcall: entering group for request 1154
INFO RadiusServer.Radius - rlm_ldap: searching for user <myUsername>@<myDomain>.se in AD:ad01.<myDomain>.se
DEBUG RadiusServer.Radius - radius_xlat: Running registered xlat function of module authsrc_3001 for string 'Username'
DEBUG RadiusServer.Radius - rlm_ldap: - ldap_xlat
DEBUG RadiusServer.Radius - radius_xlat: Running registered xlat function of module authsrc_3001 for string 'Username'
DEBUG RadiusServer.Radius - rlm_ldap: - ldap_xlat
DEBUG RadiusServer.Radius - radius_xlat: Running registered xlat function of module authsrc_3001 for string 'Username'
DEBUG RadiusServer.Radius - rlm_ldap: - ldap_xlat
DEBUG RadiusServer.Radius - radius_xlat: '(&(|(userPrincipalName=<myUsername>@<myDomain>.se@<myDomain>.se)(sAMAccountName=<myUsername>@<myDomain>.se)(userPrincipalName=<myUsername>@<myDomain>.se))(objectClass=user))'
DEBUG RadiusServer.Radius - radius_xlat: 'ou=_**,dc=<myDomain>,dc=se'
DEBUG RadiusServer.Radius - rlm_ldap: ldap_get_conn: Checking Id: 0
DEBUG RadiusServer.Radius - rlm_ldap: ldap_get_conn: Got Id: 0

But in my TEAP service when I check the same parse where it instead uses the attribute "Authentication:TEAP-Method-2-Username" my username doesn't get added to the ldap search string:

DEBUG RadiusServer.Radius - modcall: entering group svc_TEAP test TYR 802.1X Wireless_inner_3007 for request 1088
DEBUG RadiusServer.Radius - modcall: entering group for request 1088
INFO RadiusServer.Radius - rlm_ldap: searching for user <myUsername>@<myDomain>.se in AD:ad01.<myDomain>.se
DEBUG RadiusServer.Radius - radius_xlat: Running registered xlat function of module Authentication for string 'TEAP-Method-2-Username'
DEBUG RadiusServer.Radius - radius_xlat: '(&(userPrincipalName=)(objectClass=user))'
DEBUG RadiusServer.Radius - radius_xlat: 'ou=_**,dc=<myDomain>,dc=se'
DEBUG RadiusServer.Radius - rlm_ldap: ldap_get_conn: Checking Id: 0
DEBUG RadiusServer.Radius - rlm_ldap: ldap_get_conn: Got Id: 0

Just wondering if anyone had any thoughts  on why the TEAP service doesn't add the username to the ldap search string ?

In that case I'm stumped ...

Both the UPN and what's shown in accesstracker under Method2 matches word for word so I don't understand why I would get an error that says "user not found".

Error Code:    216
Error Category:    Authentication failure
Error Message:    User authentication failed

eap-teap: Method 2 failed for transaction
TEAP_<mydomain>_AD - ad01.<mydomain>.se: User not found.
EAP-TLS: Authentication failure, unknown user
eap-teap: User authentication failed
TEAP_<mydomain>_AD - ad01.<mydomain>.se: User not found.
EAP-TLS: Authentication failure, unknown user
eap-teap: User authentication failed

The table that you show at the bottom is the attributes that are pulled from AD, with Name being the name of the attribute in AD and the Alias Name is how the attribute shows up in ClearPass... for the first line, the distinguishedName attribute's value in AD will be shown as UserDN in ClearPass... You could add here extra (non-standard/custom) attributes that you would like to pull from AD...

The Query will instruct AD to return a specific LDAP object (and it's attributes that are mapped according to the table just discussed). In the case of your Query, AD will search for an object that has the objectClass = user, and where the userPrincipleName matches the TEAP-Method-2 username (check in Access Tracker which that is). So no, your UPN would not need to match any attribute in the table.

I did as you suggested and disable the authorization and then connected to the SSID with TEAP successfully and in Access Tracker the the username for that session is displayed as myusername@mydomain.se which corresponds to the userPrincipalName in my AD.

With that said I then don't quite understand how the matching of the attributes work.

On my Authentication Source for the TEAP service the filter query for Authentication is currently set as:

(&(userPrincipalName=%{Authentication:TEAP-Method-2-Username})(objectClass=user))

If I then in the same window go to the Attributes tab and do a lookup with myusername@mydomain.se I get a hit and it displays my user account.

It's been a long day and I feel like I'm rambling a bit at this point, but I really don't understand how the matching works.

Do one of these have to match with myusername@mydomain.se or did I missunderstand what you said in your video ?

The messages that you see in the Alerts tab indicate that the username lookup in your Authentication source did not succeed.

Most times that has to do with that the lookup you do does not query the right field in your authentication source. For example, the default AD query uses the sAMAccountname field in AD, which has the 'plain username'. If you switch to EAP-TLS, it typically uses the User Principle Name (UPN) or E-mail, and those are different fields to look up the authentication attributes.

If EAP-TLS works, but TEAP doesn't, then you may either have a different LDAP Query, or you use the wrong fields from your authentication or certificate. If you temporarily disable authorization, from there check the Authentication Source lookups and fix those, This video explains a bit what's going on... it's is slightly different context but related.

I do have a seperate service that only uses EAP-TLS that works once I'm logged in.

I've used that one and verified that I could authorize both the user and computer.

It doesn't use the same Authentication source but the one for the TEAP service has a copy of it in which we've changed the filter query to include the Method 1 for the Machine and Method 2 for the user.

Just to help you reduce complexity during troubleshooting it can be useful to setup an EAP-TLS service as a test to get that working prior to moving to TEAP.

Do. you have an authorisation source that will actually work with the identity in the certificate? This might be why you are having to uncheck Authorization. If the identity doesn't match what is in your source/identity store then no match will be made.