here is a discussion http://forums.oracle.com/forums/thread.jspa?threadID=657706&start=0&tstart=0

thanks

“MUST support” is not the same as “MUST be enabled”, “MUST support” implies that the LDAP server must be able to handle it if it is enabled.

Sure the client should do some detection too, if necessary, however my view is that disabling anonymous binds on the server makes much of this argument moot.

Also, section 5.1.2 of the RFC quotes -

“Additionally, Servers SHOULD by default fail Unauthenticated Bind requests with a resultCode of unwillingToPerform”

Which is open to a little bit of interpretation, but suggests (to me) that the default should be that the Server fails unauthenticated binds (i.e default is ‘off’, with the option to turn it on).

Many LDAP servers do indeed ship with anonymous binds disabled, infact Windows 2003 Domain Controllers should ship with anonymous binds disabled (of course you can then enable if you like) -

http://support.microsoft.com/default.aspx?scid=326690

So it sounds like Patricks AD is either an earlier version (where anonymous binds were enabled by default perhaps), or has been manually enabled for anonymous binds.

John.

I’m not sure a standards-conforming LDAP server can disable anonymous binds. However, this discussion is really about “Unauthenticated Authentication” binds described in section 5.1.2. This mechanism is selected by passing a non-zero length DN and a zero-length password.

I don’t see anything indicating that a server must implement this mechanism; however, section 6.3.1 explicitly addresses the concerns raised here and says “Clients that use the results from a simple Bind operation to make authorization decisions should actively detect unauthenticated Bind requests (by verifying that the supplied password is not empty) and react appropriately.”

When this thread was brought to my attention, I was a bit surprised too; however, it appears the protocol has some features that must be accounted for when one is using a bind against an LDAP server as a way of proving that a user is who he/she says.

Rodney

>do you think that the average APEX developer will
>know about that behavior if he just wants to do
>simple LDAP integration in an custom authorization
>scheme?

No, I don’t expect the average APEX developer to know about that…

However….I most certainly expect the LDAP Administrator to know about the impact of allowing anonymous binds.

In a case where the APEX Developer *was* the same person as the LDAP Administrator, then yes…they should know about anonymous binds.

That was my point, when you use LDAP Authentication in APEX you are effectively saying “I wish to defer the maintenance and authentication of my users to another system/repository” and in that respect you have to assume that the person responsible for maintaining that repository (in this case the LDAP Directory) knows what they are doing.

There is no right or wrong answer as to whether anonymous binds should be allowed or disallowed, it’s purely an internal decision that needs to be made, based on whether you have other systems that require anonymous binds to be used or not (personally I’m not a fan of anonymous binds, however they serve a purpose).

One of the best pieces of advice I could give to anyone starting to integrate their APEX apps with their LDAP directory is to work closely with your LDAP administrator, because it will make your life much much easier (as I don’t expect the average APEX developer to already know the specific DN’s and LDAP attributes they need to use, however your LDAP administrator should be able to guide you on that).

You’re looking purely at the APEX app perspective here, sure you could take the NULL password into account and have the authenticate routines pass back false, however don’t forget that the LDAP directory could (and likely is) be used by many *many* other systems, such as SSH servers, Windows domain login, Email account authentication and so on, all of these systems can be written in a variety of languages, C, Perl, .NET etc…….

My point? Well…if your LDAP server allows anonymous binds then it will allow anonymous to any of these systems (unless they perform the explicit check themselves). Even if those systems do perform a special check themselves, someone could easily code up some Perl code (or whatever) to perform an anonymous bind in just a few lines of code.

You could easily write your own wrapper around the APEX routines to add a check for NULL password, however if you really want to disallow anonymous binds the place to do it is at the LDAP server.

John.

do you think that the average APEX developer will know about that behavior if he just wants to do simple LDAP integration in an custom authorization scheme?

I doubt not.

Would be interesting to know how many production applications are out there where this problem exists… Hopefully they all have a good QA department which captured that!

Patrick

Buried away in the LDAP server specifications somewhere I believe that it is ‘correct’ to allow an anonymous bind even if a username (i.e DN in this case) is passed in.

In other words, if you pass in a full DN and leave the password as NULL, then an LDAP directory server which supports anonymous binds will consider this a request to perform an anonymous bind (by virtue of the password being NULL), the fact that a DN has been passed in doesn’t really come into it.

Again, I don’t really see this as a flaw in APEX_LDAP since it is sort of conforming to the way an LDAP server supports anonymous binds.

I see the ‘quick solution’ if you don’t want to allow NULL passwords to treated as an anonymous binds is to disable anonymous binds.

John

Turning off anonymous binds would cause the ‘correct’ behavior that you want from the APEX_LDAP.authenticate routine.

John.

For the other functions like APEX_LDAP.is_member it’s ok to pass NULL in case you have anonymous bind enabled on your LDAP server.

But the APEX_LDAP.authenticate is security relevant and only used for authentication, that’s its purpose. Why should I want to allow anonymous authentication there? The built-in LDAP authentication scheme does the check, and I think by purpose.

Patrick

As I say your LDAP administrator can change this behaviour (I wouldn’t really want the APEX_LDAP package to try and second-guess what the anonymous binding policy was).

John