Solved!
Go to SolutionCannot authorise LDAP directory services users on 7.10.50.00
Hi,
We've faced an issue after successfully upgrading our iDRAC servers to the most recent available version, 7.10.50.00, from 7.10.30
```
racadm>>racadm get iDRAC.LDAP
[Key=iDRAC.Embedded.1#LDAP.1]
BaseDN=cn=users,cn=accounts,dc=internal,dc=company,dc=net
BindDN=
!!BindPassword=******** (Write-Only)
CertValidationEnable=Enabled
Connection=LDAPS
Enable=Enabled
GroupAttribute=member
GroupAttributeIsDN=Enabled
Port=636
SearchFilter=
Server=myldaps.company.net
UserAttribute=uid
```
This is a sample test highlighting the differences when it comes to check the user membership for authorization purposes.
On 7.10.50.00
```
09:18:48 Connecting to ldaps://[myldaps.company.net]:636...
09:18:48 Test user authenticated user=uid=username,cn=users,cn=accounts,dc=internal,dc=company,dc=net host=myldaps.company.net
09:18:48 Connecting to ldaps://[myldaps.company.net]:636...
09:18:48 Test user authenticated user= host=myldaps.company.net
09:18:48 Search command:
Bind DN: [Anonymous]
```
On 7.10.30
```
09:21:19 Connecting to ldaps://[myldaps.company.net]:636...
09:21:19 Test user authenticated user=uid=username,cn=users,cn=accounts,dc=internal,dc=company,dc=net host=myldaps.company.net
09:21:19 Search command:
Bind DN: uid=username,cn=users,cn=accounts,dc=internal,dc=company,dc=net
```
As you can see in the newer version, the LDAP Bind DN doesn't get appropriately populated because the authenticated user DN is passed empty.
We've had to rollback to 7.10.30 in order to fix this issue. Is there an internal bug being tracked about this misbehaviour? we stumbled upon this but not sure if new functionality was released. We cannot find further settings to tweak neither in the CLI now GUI
We also found an interesting thread where there's some vague talk about a new functionality in the making back in late 2023.
(edited)
Thanks @Dell-Martin S
We're neither using a BinDN nor Password. We were relying on the user DN for authentication and group membership for authorization (no actual strong criteria on this, anyone on our directory could get authenticated).
All settings are correct server LDAP wise (DNS, network reachability, etc...), I tried a few other servers in the realm. No firewall is blocking any ports in between. I shared a `test` result from a working firmware release (v7.10.30) VS a non-working `test` output (v7.10.50)
We spotted there's an extra LDAP query from the iDRAC on the newer version of iDRAC, which sends an empty "Bind DN:" to the LDAP server.
Our attribute of group membership is member, I tried with sAMAccountName and I get authentication denied, which works fine with `uid`
I did not find anything on the changelog or release notes of this version. It's quite weird.
That's correct @DELL-Charles R - This goes through as an anonymous bind.
I opened a service support request ticket on your end to see whether we can troubleshoot further. I'll DM the case number.
I'm unable to send DMs it seems.
Do you need anything else beyond what I posted on the first message?
The significant difference between v7.10.50 and v7.10.30 is that the second LDAP request sent by the iDRAC, in the new version is anonymous, whereas in the former one it uses the client credentials to perform the group membership check.
v7.10.50 Test Results Test Description Result -------------------------------------------------------------------------------- Ping Directory Server Not Run Directory Server DNS Name Passed LDAP connection to the Directory Server Passed Certificate Validation Passed User DN existence Passed User Authentication Passed User Authorization Failed Test Results -------------------------------------------------------------------------------- Test User Name myusername Test User Password **** Test Log -------------------------------------------------------------------------------- 08:17:17 Initiating Directory Services Settings Diagnostics: 08:17:17 trying LDAP server myldaps.company.net:636 08:17:17 Server Address myldaps.company.net resolved to 10.10.10.24 08:17:17 connect to 10.10.10.24:636 passed 08:17:17 Connecting to ldaps://[myldaps.company.net]:636... 08:17:18 Test user authenticated user= host=myldaps.company.net 08:17:18 Search command: Bind DN: [Anonymous] Scope: subtree Base DN: cn=accounts,dc=internal,dc=company,dc=net Search filter: (uid=myusername) Attribute list: objectClass memberOf dn uid objectCategory defaultNamingContext namingContexts ldapServiceName supportedControl supportedExtension 08:17:18 Connecting to ldaps://[myldaps.company.net]:636... 08:17:18 Test user authenticated user=uid=myusername,cn=users,cn=accounts,dc=internal,dc=company,dc=net host=myldaps.company.net 08:17:18 Connecting to ldaps://[myldaps.company.net]:636... 08:17:18 Test user authenticated user= host=myldaps.company.net 08:17:18 Search command: Bind DN: [Anonymous] Scope: base Base DN: cn=oob_admin,cn=groups,cn=accounts,dc=internal,dc=company,dc=net Search filter: (member=myusername) Attribute list: objectClass memberOf dn uid objectCategory defaultNamingContext namingContexts ldapServiceName supportedControl supportedExtension 08:17:18 ERROR: The user is not a member of any role group that allows access to iDRAC.v7.10.30 Test Results Test Description Result -------------------------------------------------------------------------------- Ping Directory Server Not Run Directory Server DNS Name Passed LDAP connection to the Directory Server Passed Certificate Validation Passed User DN existence Passed User Authentication Passed User Authorization Passed Test Results -------------------------------------------------------------------------------- Test User Name myusername Test User Password **** Test Log -------------------------------------------------------------------------------- 08:17:27 Initiating Directory Services Settings Diagnostics: 08:17:27 trying LDAP server myldaps.company.net:636 08:17:27 Server Address myldaps.company.net resolved to 10.10.10.24 08:17:27 connect to 10.10.10.24:636 passed 08:17:27 Connecting to ldaps://[myldaps.company.net]:636... 08:17:27 Test user authenticated user= host=myldaps.company.net 08:17:27 Search command: Bind DN: [Anonymous] Scope: subtree Base DN: cn=users,cn=accounts,dc=internal,dc=company,dc=net Search filter: (uid=myusername) Attribute list: objectClass memberOf dn uid objectCategory defaultNamingContext namingContexts ldapServiceName supportedControl supportedExtension 08:17:27 Connecting to ldaps://[myldaps.company.net]:636... 08:17:27 Test user authenticated user=uid=myusername,cn=users,cn=accounts,dc=internal,dc=company,dc=net host=myldaps.company.net 08:17:27 Search command: Bind DN: uid=myusername,cn=users,cn=accounts,dc=internal,dc=company,dc=net Scope: base Base DN: cn=oob_admin,cn=groups,cn=accounts,dc=internal,dc=company,dc=net Search filter: (member=uid\3dmyusername\2ccn\3dusers\2ccn\3daccounts\2cdc\3dinternal\2cdc\3dcompany\2cdc\3dnet) Attribute list: objectClass memberOf dn uid objectCategory defaultNamingContext namingContexts ldapServiceName supportedControl supportedExtension 08:17:27 Privileges gained from role group 'cn=oob_admin,cn=groups,cn=accounts,dc=internal,dc=company,dc=net': Login Config iDRAC Config User Clear Logs Server Control Virtual Console Virtual Media Test Alerts Diagnostic Command 08:17:27 Test user myusername authorized 08:17:27 Cumulative privileges gained: Login Config iDRAC Config User Clear Logs Server Control Virtual Console Virtual Media Test Alerts Diagnostic CommandAnything else you can think of?
This is the internal case number <private information removed by Mod>
(edited)
Thanks. We'll stay on 7.10.30 until a new release comes out.
By the way, is there an internal bug number or anything we could use for our own tracking?
```
You may have restricted the containers where the groups or users are at such that an ANONYMOUS bind is not able to return search attributes.
```We've not touched our IPA deployment at all. All our groups can be queried using anonymous binds. In fact, It was beautifully working prior to bumping our iDRACs to this version. Can you please elaborate of what was changed in 7.10.50.00? - I don't see any release notes that go to the important details.
Are you also saying Dell has not ack-ed this as an internal bug?
Are you saying
We have neither tweaked nor modified the default upstream freeIPA LDAP settings we use. In fact, we can perform anonymous queries on these groups in questions using the CLI, pretty much in the same way older versions of iDRAC work.
Our RPM-bundled version of IPA is 4.11.0-15.el9_4.alma.1
There's a clear difference in the LDAP query logs between v7.10.50 and v7.10.30 - Have the engineers verified that?
kitos9112
2 Intern
•
16 Posts
•
2 Points
0
0
Posted October 21st, 2024 11:07
@DELL-Young E
Hi,
We gave up on using anonymous binding DN across our Dell iDRAC gear. The iDRAC should use the authenticated user bind DN to look up group membership which is clearly not doing anymore.
This has been a breaking change that went in silently undocumented. Our systems are indeed under warranty but we cannot afford putting more time forward to tackle this issue.
Thanks,
Marcos S.