Cannot authorise LDAP directory services users on 7.10.50.00

Hello thanks for choosing Dell and welcome to our community:

To start with, what LDAP server do you use?

Respectfully,

Hello,

We use the latest version of freeIPA.

LDAP 389-ds-base version 2.4.5

Hi,

thanks, I forwarded this.

1. Verify LDAP Configuration:
   Ensure that your LDAP configuration settings are correct and consistent with the previous version. Double-check the BaseDN, BindDN, Server, Port, and other related settings.
2. Test with Different User Attributes:
   Try using different user attributes for the UserAttribute setting to see if that resolves the issue. For example, you could try using sAMAccountName instead of uid.

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.

Hello,

Typically if you do not specify BindDN I would expect it to try an anonymous bind.

Would you be able to send me a screenshot of how you are running the test with the actual format of the user?

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 Command

Hi,

maybe the DM failed because YoungAh Eun is the case owner.

@DELL-Charles R 

Anything else you can think of?

This is the internal case number <private information removed by Mod>

Hello,

Thank you for the information. I'm working with one of our SystemsManagement engineers and I can follow up with you when I have more information.

You may consider contacting support directly. They can do a remote session with you to get a look. The forum is not capable of doing that type of engagement.

Please note I removed your other case number as that is private information.

@DELL-Charles R​ 

Thanks. We'll stay on 7.10.30 until a new release comes out.

@DELL-Charles R​ 

By the way, is there an internal bug number or anything we could use for our own tracking?

You could use the SR case number that our moderator deleted.

Hello,

I have an update. They checked and verified that using default OpenLDAP and RHEL IPA SERVER users and groups locations that iDRAC can work with generic LDAP without a bind DN and no modifications to LDAP Server.

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.

There was a fix in 7.10.50.00 that ultimately made the group query also use Anonymous by design as expected. So most likely it's a permissions thing on the groups.

Option 1: Enable permissions for Anonymous to work on the groups in question

Option 2: Leverage a Service Account and specify Bind DN

See if that helps. You may consider contacting support directly. They can do a remote session with you to get a look.

The forum is not capable of doing that type of engagement.