Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Highlighted
Anonymous_User Absent Member.
Absent Member.
576 views

LDAP: Disable Unauthenticated Auth, but keep Anonymous Auth


According to the LDAP specification, you will achieve an anonymous bind
by binding with EITHER an empty DN or an empty password.
As an example, a bind with DN cn=admin,o=world and an empty password
should be treated as an anonymous bind.

This is fine for the LDAP server itself, but it is problematic if you
have LDAP clients that tries to authenticate users and allows an empty
password. The LDAP client will in this case receive a successful bind
from the LDAP server.
Yes, it is an anonymous bind, but the LDAP client would interpret this
as the user was authenticated OK and give the user whatever access she
is entitled to within the LDAP client (which could be a web application
or whatever).

Because of this, most (but not all) LDAP clients prevent empty password
when authenticating users.
I personally know of several LDAP clients that allow empty passwords,
and we have a couple of them in use in my organization.

I thus want to disable Unauthenticated Authentication (DN set, but
password empty, resulting in anonymous bind), while keeping regular
Anonymous Authentication (empty DN).

The method described in the below support article disables both
Unauthenticated Authentication (the one I want to disable) and
Anonyomous Authentication (which I want to keep).
https://www.novell.com/support/kb/doc.php?id=3449660

According to RFC-4513 (LDAP Authentication Methods...) "Servers SHOULD
by default fail Unauthenticated Bind requests with a resultCode of
unwillingToPerform."
See: https://tools.ietf.org/html/rfc4513#section-5.1.2

I find no way of configuring this behavior in eDirectory.

Does anyone have any good advice?


--
oyvindhal
------------------------------------------------------------------------
oyvindhal's Profile: https://forums.netiq.com/member.php?userid=9409
View this thread: https://forums.netiq.com/showthread.php?t=53466

Labels (1)
0 Likes
6 Replies
Knowledge Partner
Knowledge Partner

Re: LDAP: Disable Unauthenticated Auth, but keep Anonymous Auth

On Tue, 12 May 2015 13:34:01 +0000, oyvindhal wrote:

> According to the LDAP specification, you will achieve an anonymous bind
> by binding with EITHER an empty DN or an empty password. As an example,
> a bind with DN cn=admin,o=world and an empty password should be treated
> as an anonymous bind.
>
> This is fine for the LDAP server itself, but it is problematic if you
> have LDAP clients that tries to authenticate users and allows an empty
> password. The LDAP client will in this case receive a successful bind
> from the LDAP server.


Yep. The client that does this is broken.


> Yes, it is an anonymous bind, but the LDAP client would interpret this
> as the user was authenticated OK and give the user whatever access she
> is entitled to within the LDAP client (which could be a web application
> or whatever).


Yep, I've seen this happen in homegrown applications and expen$ive
commercial ones as well. It seems to me that most programmers of
applications don't actually understand LDAP.


> Because of this, most (but not all) LDAP clients prevent empty password
> when authenticating users.


Those that don't are fundamentally broken and need to be fixed.


> I personally know of several LDAP clients that allow empty passwords,
> and we have a couple of them in use in my organization.
>
> I thus want to disable Unauthenticated Authentication (DN set, but
> password empty, resulting in anonymous bind), while keeping regular
> Anonymous Authentication (empty DN).
>
> The method described in the below support article disables both
> Unauthenticated Authentication (the one I want to disable) and
> Anonyomous Authentication (which I want to keep).
> https://www.novell.com/support/kb/doc.php?id=3449660
>
> According to RFC-4513 (LDAP Authentication Methods...) "Servers SHOULD
> by default fail Unauthenticated Bind requests with a resultCode of
> unwillingToPerform."
> See: https://tools.ietf.org/html/rfc4513#section-5.1.2
>
> I find no way of configuring this behavior in eDirectory.
>
> Does anyone have any good advice?


Nope, not really. Since both scenarios are valid anonymous binds, both
succeed. It would be nice to be able to force one of them to fail,
though. At the moment, the only suggestion I can make is to put this in
RMS (http://www.novell.com/rms).



--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.microfocus.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Knowledge Partner
Knowledge Partner

Re: LDAP: Disable Unauthenticated Auth, but keep Anonymous Auth

Agreed to all points.

I believe there is already an enhancement to modify the LDAP service to
handle standards-non-compliant clients like this, but ultimately this is
something a client should fix. Since the fact that the user has no rights
(other than [Public] rights) during this bind means they are likely not
seeing things they expect (assuming their login does something like pulls
in their first and last name, or other data that they alone can access) so
they'll need to re-login anyway, unless they're merely doing a bind and
then the application is doing authorization on its side (in which case
this probably lets anybody login as anybody else due to bad code; I think
this is your case).

From the same section of the RFC where you quoted what servers should do
are two notes about what clients also SHOULD do, which apparently yours is
now:


Clients SHOULD be implemented to require
user selection of the Unauthenticated Authentication Mechanism by
means other than user input of an empty password. Clients SHOULD
disallow an empty password input to a Name/Password Authentication
user interface.


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Knowledge Partner
Knowledge Partner

Re: LDAP: Disable Unauthenticated Auth, but keep Anonymous Auth

On Tue, 12 May 2015 17:59:52 +0000, ab wrote:

> Agreed to all points.
>
> I believe there is already an enhancement to modify the LDAP service to
> handle standards-non-compliant clients like this, but ultimately this is
> something a client should fix. Since the fact that the user has no
> rights (other than [Public] rights) during this bind means they are
> likely not seeing things they expect (assuming their login does
> something like pulls in their first and last name, or other data that
> they alone can access) so they'll need to re-login anyway, unless
> they're merely doing a bind and then the application is doing
> authorization on its side (in which case this probably lets anybody
> login as anybody else due to bad code; I think this is your case).


Yes, this is exactly what I see broken applications doing. They get the
idea that the equivalent of:

username=get-user-name()
password=get-user-password()

login=do-ldap-bind(username,password)

if (login = ok)
Then do stuff in application
else
Fail

is a good idea. It tests ok, because they only test it with valid and not-
valid user/password combinations. They completely miss the idea that a
null password is an anonymous bind, and returns success. So, now anybody
can log in as any user, just by specifying the right user name and no
password.


> From the same section of the RFC where you quoted what servers should do
> are two notes about what clients also SHOULD do, which apparently yours
> is now:
>
>

> Clients SHOULD be implemented to require user selection of the
> Unauthenticated Authentication Mechanism by means other than user input
> of an empty password. Clients SHOULD disallow an empty password input
> to a Name/Password Authentication user interface.
>


Yep.

But I still like the idea of being able to deliberately and permanently
break applications that are brain damaged enough to be broken like this
without it currently being obvious that they are broken.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.microfocus.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Knowledge Partner
Knowledge Partner

Re: LDAP: Disable Unauthenticated Auth, but keep Anonymous Auth

David Gersic wrote:

> They get the
> idea that the equivalent of:
>
> username=get-user-name()
> password=get-user-password()
>
> login=do-ldap-bind(username,password)
>
> if (login = ok)
> Then do stuff in application
> else
> Fail
>
> is a good idea.


Which is how all other user/password based, non-LDAP authentication works. Not
a too unreasonable assumption, IMHO.

> They completely miss the idea that a
> null password is an anonymous bind


Which is completely counter-intuitive and unnecessary as another anonymous bind
scenario (empty DN) exists and is much easier to follow. One could therefore
well argue LDAP is broken by providing two redundant anonymous bind options,
one of which is not only superfluous but also easy to misinterpret and hard to
test properly. Just because it's laid down in an RFC and has been around for a
long time does not mean it makes all that much sense.

There might even be good use cases for allowing different logins without
password (and not have them all treated as anonymous binds with the same access
rights), e.g. if security is not a concern in a closed environment and would
only complicate a setup unnecessarily, but making apps see only what they need
to see via ACLs would be helpful (e.g. by avoiding having to implement logic
inside the app to filter down search results). Not a top-ten LDAP use case, but
why limit possibilities unnecessarily? Not allowing empty passwords should be a
configration option, IMHO, and return a proper error code/message when enabled.

Of course LDAP is as it is now and apps/clients have to deal with all it's
oddities in the real world. I just do not think it's fair to blame side effects
of unnecessarily complicated and misleading standards only on app devs. If LDAP
was a proprietry standard by Microsoft it would most likely be them you would
blame to have it screwed up instead.
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: LDAP: Disable Unauthenticated Auth, but keep Anonymous Auth


Thank you all for your opinions on the subject. I agree that
applications should be fixed, but I see no conflict in acknowledging
that, and at the same time give directory administrators the possibility
of protecting their organizations against the ones that are broken.

I have thus created an enhancement request (103372) and will see how
NetIQ responds.


--
oyvindhal
------------------------------------------------------------------------
oyvindhal's Profile: https://forums.netiq.com/member.php?userid=9409
View this thread: https://forums.netiq.com/showthread.php?t=53466

0 Likes
Knowledge Partner
Knowledge Partner

Re: LDAP: Disable Unauthenticated Auth, but keep Anonymous Auth

On Wed, 13 May 2015 07:22:09 +0000, Lothar Haeger wrote:

> David Gersic wrote:
>
>> They get the
>> idea that the equivalent of:
>>
>> username=get-user-name()
>> password=get-user-password()
>>
>> login=do-ldap-bind(username,password)
>>
>> if (login = ok)
>> Then do stuff in application
>> else
>> Fail
>>
>> is a good idea.

>
> Which is how all other user/password based, non-LDAP authentication
> works. Not a too unreasonable assumption, IMHO.
>
>> They completely miss the idea that a
>> null password is an anonymous bind

>
> Which is completely counter-intuitive and unnecessary as another
> anonymous bind scenario (empty DN) exists and is much easier to follow.


Agreed.


> One could therefore well argue LDAP is broken by providing two redundant
> anonymous bind options, one of which is not only superfluous but also
> easy to misinterpret and hard to test properly. Just because it's laid
> down in an RFC and has been around for a long time does not mean it
> makes all that much sense.


It doesn't make sense at all, you're right there. But, good or bad, it
_is_ the standard, it is documented, it's well known, and even a little
bit of research would turn up the information. It's also not difficult to
test. If you're only getting two parameters (username/password), you
should test for how it works or fails without one, the other, or both,
and handle it accordingly.

LDAP is broken by design here. It's doing exactly what it says on the
tin. The application is broken by a failure of understanding and a
failure of testing.


> Not allowing empty passwords should be a configration
> option, IMHO, and return a proper error code/message when enabled.


Agreed. RFC-4513, 5.1.2 seems like a good idea and a worthwhile
enhancement.


> Of course LDAP is as it is now and apps/clients have to deal with all
> it's oddities in the real world. I just do not think it's fair to blame
> side effects of unnecessarily complicated and misleading standards only
> on app devs. If LDAP was a proprietry standard by Microsoft it would
> most likely be them you would blame to have it screwed up instead.


Nope, not in this case. As long as the standard is published, and the
code does what the documentation says it should do, it's working
correctly. Oddly, I'll grant you that, but correctly.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.microfocus.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.