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.
Has anybody observed such behaviour before? What could cause this?
-->>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.
Sorry to say, but I've a doubt tha tyou are familirly how to setup LDAP.
--->>>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.
and here is the Issue!
Is probable that the LDAP work fine, for any user user without authentication, or for a user you in LDAP and save the password.
User and Password in LDAP will be handle primary by LDAP and then in FOS.
I would suggest to check the User Group in LDAP and set correct permission in the group.
Appreciate your reply, but let's clarify a couple of things:
->Sorry to say, but I've a doubt tha tyou are familirly how to setup LDAP.
TBH, the settings on FOS for LDAP are quite simple.
Admittedly, I am not familiar with Windows AD / LDAP administration, if that's what you mean?
->Is probable that the LDAP work fine, for any user user without authentication, or for a user you in LDAP and save the password.
I don't understand what you are trying to say. Are you referring to anonymous binding?
->User and Password in LDAP will be handle primary by LDAP and then in FOS.
That's perfectly clear, it's why we want to use it in the first place :smileyhappy:
->I would suggest to check the User Group in LDAP and set correct permission in the group.
OK, what kind of permission problem on the User Group will allow FOS to authenticate user with WRONG password? Omitting the password does not produce the same result.
How do you explain the LDAP works fine for other applications (using different binding techniques - anonymous, SASL), but not for FOS?
are you sure the switch username/credetntial i.e.
admin - password, are not pemanetly stored in the LDAP ?
any such BUG or DEFECT from a FOS side is unknown to me, excepted the BASH shell security, but this was closed in 7.2.1c1
( you are in "d" )
I insist to say that the Issue is on LDAP and not in the FOS.
Try from command line HAreboot, for details see command ref. manuals, is probable a preview login hang and the sessions remain open ????
Alternative, Upgrade the FOS to major Patch release 7.2.1g is free of BUG
-> are you sure the switch username/credetntial i.e. admin - password, are not pemanetly stored in the LDAP
-> any such BUG or DEFECT from a FOS side is unknown to me
Yes, I checked all the DEFECTS in later FOS versions, found nothing
-> I insist to say that the Issue is on LDAP and not in the FOS.
I agree with you, but the question is, how to approach the LDAP server administrator with this issue, if the same AD User Group is working correctly with several different applications.
-> Try from command line HAreboot
This was already done on the original switch, but didn't help. Also a fresh new switch was used. Will try to do a hareboot on the new switch as well, just to make sure.
-> Alternative, Upgrade the FOS to major Patch release 7.2.1g is free of BUG
We are planning an upgrade of the test switch to 7.3.1d. I believe it has the same bugfixes as 7.2.1g, right?
It's truly an unusual phenomenon, and it hasn't happened to me before..
Anyway, I did another test after performing hareboot. See the (anonymised) session log below:
Login: adminadmin@testswitch:admin>testswitch:admin>testswitch:admin> ldapcfg --showLDAP Role | Switch Role------------------------------------------------BRCDADM | admin------------------------------------------------testswitch:admin>testswitch:admin> aaaconfig --showRADIUS CONFIGURATIONS=====================RADIUS configuration does not exist.
Position : 1Server : ldapserver.customer.comPort : 389Domain : customer.comTimeout(s) : 3
TACACS+ CONFIGURATIONS=====================TACACS+ configuration does not exist.
Primary AAA Service: LDAPSecondary AAA Service: Switch databasetestswitch:admin>testswitch:admin> harebootWrite failed: Connection reset by peer
TEST1 (with the unexpected result):
testswitch:ldapuser> userconfig --show
Account name: ldapuserDescription: Remote AccountEnabled: YesPassword Last Change Date: Unknown (UTC)Password Expiration Date: Not Applicable (UTC)Locked: NoRole: adminAD membership: 0Home AD: 0testswitch:ldapuser>
TEST2 (with the expected result, confirming group membership is verified):
Login: ldapuserNOTmember@ldapuserNOTmember@ldapuserNOTmember@Permission denied (publickey,password).
The switch local database only containd the factory configured users (root, factory, admin, user)The question is now, what on the AD/LDAP server side could be causing this...
When browsing the AD, the only unusual thing I noticed was the use of a dash (-) character in some OUs involved, like this:
"CN=BRCDADM,OU=Groups - Security,OU=Org Unit,DC=customer,DC=com"
"CN=ldapuser,OU=12345678 - DEPARTMENT,OU=Org Unit,DC=customer,DC=com"
Don't remeber seeing my other customers using dashes in OUs. It can be a total kick in the dark, but I don't have any other ideas at this moment... Any thoughts on this?
No change after upgrading to v7.3.1d...
For the sake of it, after the upgrade I also removed & reinstated the ldap/aaa configuration, but I can still login with any password.
Tried changing the LDAP port to 3268 (Global Catalog), but got the same result.
we assuming as you wrote in the first post, FOS v7.2.1d have a BUG/DEFECT.
Now you have Upgrade to v7.3.1d and wrote follow:
-->>No change after upgrading to v7.3.1d...
Now is the question:
1) Should we continue to discussed about any BUG or DEFECT in any FOS Release in order to solve you problem ?
2) Or we should try to find a Issue in you LPAD Config ?
I think of Option 2) is more suitable.
Generally, AD/LDAP is a hard nuts. I insist that the credential or somewaht is saved/store in the LDAP UserGroup maybe in the Registry or whatever, and you should review this one.
Infact, this is not a BUG in the FOS, that would be Fatal!
can you please try follow ? this don't have any impact with a Switch in Question or a Fabric no matter if Productive or no.
can you change temporarely the IP address on the switch in question ? what happened ?
--->>> I am thinking this might potentionally be a bug that was not previously discovered in FOS.
--->>> - AD is somehow misconfigued (no idea in what way), or--->>> - FOS misinterprets the response of the AD for some reason.
Then you should open a call with Brocade Support or you OEM Vendor if you are the opinion that this is a BUG.
I'll try to forward internally this Threads to Support for review.
Well, I already had a call open with Brocade about the issue (see the initial post).
Since customer is not comfortable with allowing us to use tcpdump/wireshark on the AD (due to security concerns), and they dont have audit logging enabled (performance concerns, as they have more than 50k users), that investigation stopped dead in its tracks.
I am currently most interested in two things, both AD related:
- Either confirm or deny my suspicion about the dashes in OUs causing these problems.
- Find out if there are any settings on the AD side that could cause this kind of behaviour on FOS.
--->>>I am currently most interested in two things, both AD related:
I'm not sure, but I'll try to find out.
And to be honestly I'm not sure how Linux ( FOS is Linux Based ) handle dashes in such certain case.
I've forward the Thread to Support, only with the question of any such BUG.
I'm not an LDAP nor AD admin, so excuse me if my terminology is a bit off.
We have dashes in group names, no issues. I verified it with one of the groups the user was a member of. It also works with long usernames (I tested up to 13 characters). I could not test usernames w/ dashes, but I think its an allowed character for local accounts and LDAP groups, so I don't see why that would be a problem w/ LDAP users..
After banging my head for a day getting ours to work, what I did find is:
* the username that you must specify when logging in should match the userPriciplalName EXACTLY as reported in ldapsearch even if it has an @domain suffix, AND
* the domain you specify in aaaConfig should exactly match your combined DC, AND
* the group must be of type Global/Security, others won't work.
Here's the conclusion of this story... We worked on this in private with Brocade support, so I felt the need to share the results in this thread.
After investigation, this issue is reproducible with both OpenLDAP & Windows AD directory environments if the directory service is configured to allow anonymous access.
Because a directory service that allow anonymous access will allow ldap searches and binds without authentication, FOS will receive the data it is querying for, and as such will consider the user as authenticated (user is who they say they are).
FOS will then proceed with additional queries to determine authorization (what user is authorized for, ie. group membership). If the user is a member of a group configured to allow access (via ldapcfg --maprole command on the switch), then the switch will allow the login to complete.
Recommendation is for customer to disable anonymous access to the directory services, or not use LDAP authentication.
Engineering will be making changes in future code (tentatively 7.4.2) releases that will prevent logins with incorrect or null passwords in AD environments that have anonymous AD access enabled. The changes should be made under DEFECT000602285.
Thanks to everyone who contributed to this thread!
Glad support was able to help you out and huge thank you for coming back to the board and posting the resolution to help others!
in the meantime, take a look on this article please.