Turn on suggestions
![]() Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
|
01-28-2016 11:18 AM - edited 01-28-2016 11:21 AM
Hi,
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?
Solved! Go to Solution.
01-28-2016 11:43 AM
dkosmac,
you wrote:
-->>My customer is trying to setup LDAP for their switches to authenticate users (using MS Win AD).
That fine.
Continue:
-->> 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.
continue:
--->>>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.
01-28-2016 12:00 PM
Hi Antonio,
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?
01-28-2016 12:15 PM
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
01-28-2016 12:27 PM
-> are you sure the switch username/credetntial i.e. admin - password, are not pemanetly stored in the LDAP
Yes, 100%
-> 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?
01-28-2016 03:02 PM
01-30-2016 11:44 PM
Hi Alexey,
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: admin
admin@<testswitch_IP>'s password:
testswitch:admin>
testswitch:admin>
testswitch:admin> ldapcfg --show
LDAP Role | Switch Role
------------------------------------------------
BRCDADM | admin
------------------------------------------------
testswitch:admin>
testswitch:admin> aaaconfig --show
RADIUS CONFIGURATIONS
=====================
RADIUS configuration does not exist.
LDAP CONFIGURATIONS
===================
Position : 1
Server : ldapserver.customer.com
Port : 389
Domain : customer.com
Timeout(s) : 3
TACACS+ CONFIGURATIONS
=====================
TACACS+ configuration does not exist.
Primary AAA Service: LDAP
Secondary AAA Service: Switch database
testswitch:admin>
testswitch:admin> hareboot
Write failed: Connection reset by peer
-------------------------
TEST1 (with the unexpected result):
Login: <valid_ldap_user_and_memberof_BRCDADM>
ldapuser@<testswitch_IP>'s password: <-- INPUT WRONG PASSWORD!
testswitch:ldapuser>
testswitch:ldapuser>
testswitch:ldapuser>
testswitch:ldapuser> userconfig --show
Account name: ldapuser
Description: Remote Account
Enabled: Yes
Password Last Change Date: Unknown (UTC)
Password Expiration Date: Not Applicable (UTC)
Locked: No
Role: admin
AD membership: 0
Home AD: 0
testswitch:ldapuser>
-------------------------
TEST2 (with the expected result, confirming group membership is verified):
Login: <valid_ldap_user_NOT_memberof_BRCDADM>
ldapuserNOTmember@<testswitch_IP>'s password:
ldapuserNOTmember@<testswitch_IP>'s password:
ldapuserNOTmember@<testswitch_IP>'s password:
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?
Thanks,
David
01-31-2016 03:46 AM
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.
BR,
D.
01-31-2016 06:47 AM
Hi,
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 ?
01-31-2016 07:35 AM