ISE 1.1.1. and additional LDAP attribute retrieval

[Karel Navratil]

Hello All,

I'm authenticating users against Active Directory and want to also check additionals attributes from LDAP. In ACS 5.3. it was possible to set this up via External Identity Sequence, but in ISE I don't see this possibility. I can set sequence only for authentication, but not for additional attribute retrieval.

When I set a condition in a policy that an LDAP attribute must match with some value, the attribute is not retrieved and autorization ends on default Deny Access.

Can anyone help me how this can be set on ISE?

Thanks!

Regards

Karel Navratil

[Tarik Admani]

Karel,

I am curious to the attribute that you are trying to retrieve, if you are trying to map the memberOf attribute then you can do that in your authorization policy. Or you can retrieve any attribute from Active Directory (external identity sources > Active Directory > Attributes).

You are correct that ISE doesnt have the feature like ACS 5 does, but in most cases I have seen this used when authentication is being done to a token server for example and the attributes were pulled from AD. Just curious to see if you need this since you are using AD as your authentication database.

Thanks,

Tarik Admani
*Please rate helpful posts*

[Karel Navratil]

Hi Tarik,

The intention is to authenticate user against Active Directory and then get an attribute value from company's LDAP server according to stripped username (not AD LDAP). If the attribute matches value Employees than the access is granted.

I've set up AD connection, I've set up LDAP connection to our company's LDAP ... but cannot find a way how to tell ISE to authenticate user via AD and if the authentication is sucessful retrieve LDAP attribute.

Our intention is that not every user in AD will have a privilege to use WLAN. And this is controlled by LDAP attribute.

In past we had a problem on ACS that ACS were not able to get group members from some trusted domains in AD forrest. So we switched to company's LDAP.

Hope it's more clear.

Regards

Karel

[Tarik Admani]

What trusts type are you using in your AD infrastructure? If you are using an external trust type (forest level trusts do not allow kerberos authentication) then that should get you past the group retrieval issues.

You can consider the option of using radius proxy feature so you can authenticate to your ACS, and open a TAC case to see when this feature will be available in ISE.

Thanks,

Tarik Admani
*Please rate helpful posts*

[Karel Navratil]

I have no idea about AD infrastructure as this is maintained by different deparment. To proxy authentication requests to ACS is not the option as I want to use EAP-Chaining feature instead of MAR.

I still cannot believe that features which ACS 5.x has was not implemented into ISE.

Regards

Karel

[Tarik Admani]

It caught me off guard also, I assumed it was there till you brought it up and checked the identity store sequence.

Your best bet is to forward this document over to your AD team to see if they can look into the trust, my bet is that you probably used acs 4 which ran on a windows platform that used ntlm for client authentication against windows. When acs 5.x was re-archtected that protocol changed to kerberos which causes headaches in multi-domain and multi-forest environments.

I would however request that you open a tac case to see if this is a feature that is expected to be released in 1.2.

Here is a guide that explains this and hopefully the AD folks will understand.....(hopefully ;-))

http://blogs.technet.com/b/surama/archive/2009/04/06/kerberos-authentication-problem-with-active-directory.aspx

Thanks,

Tarik Admani
*Please rate helpful posts*

[jrabinow]

ISE does have the functionality equivalent of identity sequences that are available as in ACS.  The implementation is in a slightly different way.

In ACS would define two separate sequences:

- one for DBs to check for authentication

- one of DBs to check for authorization

In ISE this is implemented slightly differently

- the sequence defines the DBs for authentication only

- if there are additional attributes you want then can refer to them directly in the authorization policy without having to define in a sequence

In your case, define the attributes in LDAP and then select them for conditions in the authorization policy.

[Karel Navratil]

Yes that's what I've tried as I wrote in my first post, but the ISE does not retrieve the attribute from LDAP

Here are some screenshots:

authorization rule:

ldap attribute in external identity source:

and the logs:

11001  Received RADIUS Access-Request

11017  RADIUS created a new session

11105  Request received from a device that is configured with KeyWrap in ISE.

Evaluating Service Selection Policy

15048  Queried PIP

15048  Queried PIP

15004  Matched rule

11507  Extracted EAP-Response/Identity

12100  Prepared EAP-Request proposing EAP-FAST with challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12102  Extracted EAP-Response containing EAP-FAST challenge-response and accepting EAP-FAST as negotiated

12800  Extracted first TLS record; TLS handshake started

12805  Extracted TLS ClientHello message

12806  Prepared TLS ServerHello message

12807  Prepared TLS Certificate message

12810  Prepared TLS ServerDone message

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

12812  Extracted TLS ClientKeyExchange message

12804  Extracted TLS Finished message

12801  Prepared TLS ChangeCipherSpec message

12802  Prepared TLS Finished message

12816  TLS handshake succeeded

12149  EAP-FAST built authenticated tunnel for purpose of PAC provisioning

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

12209  Starting EAP chaining

12218  Selected identity type 'User'

12125  EAP-FAST inner method started

11521  Prepared EAP-Request/Identity for inner EAP method

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

12212  Identity type provided by client is equal to requested

11522  Extracted EAP-Response/Identity for inner EAP method

11806  Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

11808  Extracted EAP-Response containing EAP-MSCHAP challenge-response for inner method and accepting EAP-MSCHAP as negotiated

Evaluating Identity Policy

15006  Matched Default Rule

15013  Selected Identity Store - Internal Endpoints

22043  Current Identity Store does not support the authentication method; Skipping it

24210  Looking up User in Internal Users IDStore - test,host/test-pc

24216  The user is not found in the internal users identity store

24430  Authenticating user against Active Directory

24402  User authentication against Active Directory succeeded

22037  Authentication Passed

11824  EAP-MSCHAP authentication attempt passed

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

11810  Extracted EAP-Response for inner method containing MSCHAP challenge-response

11814  Inner EAP-MSCHAP authentication succeeded

11519  Prepared EAP-Success for inner EAP method

12128  EAP-FAST inner method finished successfully

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

12126  EAP-FAST cryptobinding verification passed

12200  Approved EAP-FAST client Tunnel PAC request

12219  Selected identity type 'Machine'

12125  EAP-FAST inner method started

11521  Prepared EAP-Request/Identity for inner EAP method

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

12212  Identity type provided by client is equal to requested

11522  Extracted EAP-Response/Identity for inner EAP method

11806  Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

11808  Extracted EAP-Response containing EAP-MSCHAP challenge-response for inner method and accepting EAP-MSCHAP as negotiated

Evaluating Identity Policy

11055  User name change detected for the session. Attributes for the session will be removed from the cache

15006  Matched Default Rule

15013  Selected Identity Store - Internal Endpoints

22043  Current Identity Store does not support the authentication method; Skipping it

24210  Looking up User in Internal Users IDStore - test,host/test-pc

24216  The user is not found in the internal users identity store

24431  Authenticating machine against Active Directory

24470  Machine authentication against Active Directory is successful

22037  Authentication Passed

11824  EAP-MSCHAP authentication attempt passed

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

11810  Extracted EAP-Response for inner method containing MSCHAP challenge-response

11814  Inner EAP-MSCHAP authentication succeeded

11519  Prepared EAP-Success for inner EAP method

12128  EAP-FAST inner method finished successfully

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

12126  EAP-FAST cryptobinding verification passed

12201  Approved EAP-FAST client Machine PAC request

Evaluating Authorization Policy

15004  Matched rule

15016  Selected Authorization Profile - DenyAccess

15039  Rejected per authorization profile

12855  PAC was not sent due to authorization failure

12105  Prepared EAP-Request with another EAP-FAST challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

11105  Request received from a device that is configured with KeyWrap in ISE.

12104  Extracted EAP-Response containing EAP-FAST challenge-response

11514  Unexpectedly received empty TLS message; treating as a rejection by the client

12512  Treat the unexpected TLS acknowledge message as a rejection from the client

11504  Prepared EAP-Failure

11003  Returned RADIUS Access-Reject

So no any information that ISE tries to retrieve something from LDAP.

Regards

Karel

[Tarik Admani]

Karel,

Not only are the authorization poilcies used from a top to bottom (first match approach) they are also processed from the left to the right. Can you try moving the eap chaining from the left to the right, and the ldap condition from the right to the left and post the same results you did above....

thanks,

Tarik Admani
*Please rate helpful posts*

[jrabinow]

The best way to see the attributes that were received during the evaluation of the request is to look at the authentication details and view the "Other Attributes" informaiton. Attributes retrieved during the policy evaluation should be listed.

It is hard to make a full assessment without looking at the full authorization policy. Based on the information that I see can confirm Tariq's assessment that if the EAP chaining condition did not evaluation as true then no further conditions in that rule woul dbe evaluated (for performance reasons) and so the LDAP attribute would not be retrived.

[Karel Navratil]

Other Attributes:

ConfigVersionId=23,Device   Port=32769,DestinationPort=1812,RadiusPacketType=AccessRequest,Protocol=Radius,Framed-MTU=1300,State=37CPMSessionID=0a04f83500000020503e264c;31SessionID=dc2ise1v/134934281/15;,Airespace-Wlan-Id=11,DetailedInfo=Authentication   succeed,NACRadiusUserName=test,NACRadiusUserName=host/test-pc,CPMSessionID=0a04f83500000020503e264c,EndPointMACAddress=00-24-D6-75-EC-BE,EapChainingResult=User  and machine both succeeded,Device Type=Device Type#All Device  Types,Location=Location#All  Locations,IdentityAccessRestricted=false,Device IP  Address=10.x.y.z,Called-Station-ID=c4-0a-cb-89-07-70:office

So I think, that the EapChainingResult is matched, but no LDAP attributes received.

[jrabinow]

You are right that dont see the LDAP attribute in the Other Attributes

Two more things I can think of:

1) Use of matches attribute. Following syntax needs to be used

- Starts With: ^(string).*  so that ^(172).*   as the inputted text would match a string like 172greenbottles

- Ends With: .*(string)$   so that .*(211)$ as the inputted text would match a string like hello211

I am not sure about the syntax for contains and will check this a little later (maybe  .*(text).*      )

So can try one of these or just change to an equals operation

2) Do a stop/start just in case some notifications are missing

[Karel Navratil]

No, even reload of ISE server didn't help.

To me it looks that it's not doing any checks from external identities. I tried to disable LDAP and use of AD groups, but in authentication log I cannot see any message about group retrieval as I was used from ACS.

I also disabled EAP Chaining support in Policy elements but also without any change.

[Karel Navratil]

Now I got it working.

After creating Simple Condition under Authorization in Policy Elements and then using it in Authorization Policy rule it started to work.

Regards

Karel

[Brian Schultz]

Karel,

Can you share more details about your solution?  I am having a very similiar issue where I do not see AD group attributes in the Other Attributes details and am trying to build my authorization policy to match on a specific AD group (Domain Computers).

Thanks,

Brian