LDAP authenticating with wrong password - FOS v7.2.1d

My customer is trying to setup LDAP for their switches to authenticate users (using MS Win AD). We are familiar with how to setup the FOS side of things (aaaconfig --add, ldapcfg --maprole, aaaconfig --authspec), but we observe unexpected behaviour.

The issue is:

Login is successful with ANY (i.e. wrong!) password, as long as the user is a member of the mapped AD group.

Obviously, the LDAP connection works fine, as we see the group membership being verified. However, we don’t understand how it can authenticate a user with a wrong password.

May I add, the supportsaves from the switch were examined by Brocade support (case# available privately), which concluded the issue resides on their LDAP server allowing such login. The investigation stopped at Brocade support's request for tcpdump/wireshark traces, or audit logs from the LDAP server. Customer does not allow network traffic sniffing on the AD server, nor do they maintain an audit log of login attempts. This is a production AD environment, serving tens of thousands of users and a number of applications using LDAP for authentication correctly.

Additionally, we could replicate the behaviour on a newly procured switch, starting with factory default configuration (on the same FOS v7.2.1d). The next step we are going to take is to upgrade this test switch to a higher FOS version.

Re: LDAP authenticating with wrong password - FOS v7.2.1d

- The user logged in on the workstation used for testing is a different one than either used for the SSH login.- The user's password is NOT saved on this workstation, not in registry, or any of the two SSH clients used for testing (PuTTY, MobaXterm).- We are testing a new switch.- Changing the IP is not an easy task at this customer, so this is out of the question. It's a fresh new switch anyway, for which nobody ever used the credentials that are being used for testing.

Can you explain:- How would an SSH session login use any password stored in Windows registry, even if it were there. I could potentially imagine WebTools GUI doing that, but it was never even opened for this switch.

I am thinking this might potentionally be a bug that was not previously discovered in FOS. Can you (or anybody) confirm that LDAP authentication is working fine if the OU in AD contains dashes(-)?

Obviously, since the group membership is successfully verified when a wrong password is used, FOS is using anonymous binding with AD. So, it's down to two possible reasons:- AD is somehow misconfigued (no idea in what way), or- FOS misinterprets the response of the AD for some reason.

The only issue here is that I don't have a proper lab environment available, so testing any changes on the AD side is close to impossible.

Join the Broadcom Support Community

You have no obligation to provide any ideas, suggestions, comments or other feedback regarding content on the Site, Brocade and Broadcom's products or any information posted on the Site (collectively, “Contributions”). However, any Contributions You voluntarily provide may be used in Brocade and Broadcom products and related specifications or other documentation. Accordingly, if You do make any Contributions on this Site, You agree that Brocade and Broadcom may freely use, disclose, reproduce, license, distribute and otherwise commercialize the Contributions in any Brocade or Broadcom product, technology, service, specification or other documentation, as well as file for, register or otherwise assert copyright, trademark, patents and any other intellectual property rights in and to the Contributions.