LDAP authenticating with wrong password - FOS v7.2.1d [ Edited ]

[dkosmac]

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?  

[Antonio Bongiorno T…]

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.

[dkosmac]

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?

[Antonio Bongiorno T…]

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

[dkosmac]

-> 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?

[alexey.stepanov]

David, I'm impressed with what you say and subscribe to the topic. Let us know how it goes.

[dkosmac]

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

[dkosmac]

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.

[Antonio Bongiorno T…]

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 ?

[dkosmac]

Well, let's first clarify these things:

- 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.