- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Clearpass userPrincipalName users and AD Query
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Clearpass userPrincipalName users and AD Query
Hello,
if I understand correctly, user-information fetch with the Web API from Clearpass should be resolved in an AD Account by AD Query. Also the User Groups would be looked up.
I think the problem lays in the fact that we use UPN (userPrincipalName) as the login on our networks.
If I lookup a user with:
pep s u q usr <username>
PDP: <127.0.0.1, 00000000>; UID: <915a1f11>
==================================================
Client ID : <<IP-address>, 00000000>
Authentication Key : <Unavailable>
Brute force counter: 0
Username : <username>@<suffix>
Machine name : <IP-address>
User groups : <Unavailable>
Machine groups : <Unavailable>
Compliance : <Unavailable>
Identity Role : <>
Time to live : 28830
Cached time : 86400
TTL counter : 57570
Time left : 18094
Last update time : Thu Oct 4 13:57:34 2018
pdp m u <username>
Session: 915a1f11
Session UUID: {<UUID>}
Ip: <IP-address>
Users:
<username>@<suffix>@<domainname> {2b604b71}
Groups: -
Roles: -
Client Type: Identity Awareness API (Aruba ClearPass Policy Manager)
Authentication Method: Trust
Distinguished Name:
Connect Time: Thu Oct 4 13:57:34 2018
Next Reauthentication: Thu Oct 4 22:06:31 2018
Next Connectivity Check: -
Next Ldap Fetch: -
Packet Tagging Status: Not Active
Published Gateways: Local
************************************************************************************
I can see that it is working, but the User Groups aren't fetched.
On the Clearpass side, i set:
"calculate-roles":1,"fetch-user-groups":0,"fetch-machine-groups":0
(as documented by Aruba/HPE)
I read a lot of documentation and think if AD Query is working (it is) and the Web API is giving results, the correlation should be done.
Could it have to do something with the Domain-field in the LDAP Account Unit?
Thanks for any advice and kind regards,
Peter Kruppa
PS We're running R80.20
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes but it's a pretty easy fix.
See: Changing LDAP lookup type for authentication in Identity Agent
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes but it's a pretty easy fix.
See: Changing LDAP lookup type for authentication in Identity Agent
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dameon,
thanks for the fast response.
I already found that article but it is for versions: R75.40, R75.45, R75.46, R75.47, R76, R77, R77.10, R77.20, R77.30
We are running R80.20...
Kind regards,
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As far as I know, it should still be relevant for R80.20 as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Dameon, you were indeed right and it did the trick.
I didn't have access to the content and assumed it was a hotfix.
Next time I will check beforehand 🙂
Kind regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Daemon,
any idea if changing the setting to UPN will affect any other portions of identity awareness or does this only affect how the identity API interacts? If we are using AD query, radius, and portal will this also change these to UPN?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It doesn't impact other Identity Awareness functions.
