Hi This is not just an ADAM problem it's been a problem with LDAP directories for some time now and was discussed in the LDAPbis WG. As a result if you look at RFC4513(RFC2829 is obsolete) you will see this issue is now addressed by making a distinction between an anonymous authentication and an "unauthenticated authentication" mechanism. This puts the burden of checking sins of omission on the LDAP client (a RFC to beat client vendors with) but *also* allows a server to fail a bind request that populates the name but not the password.
Zero length passwords have always been a pain, the RFC has been updated to recognize that and I think you could make a change request for compliance on that basis. One other thing on the client side that you could do as a check if you can modify the app, if you bind with the dn and password provided by the user you can then read the msDS-PrincipalName attribute from ADAM rootDSE to see who you are. A more generic approach would be to bind using the dn and password and then use the RFC4532 LDAP WhoAmI (1.3.6.1.4.1.4203.1.11.3) Extended Op to see the DSA thinks you are (ADAM implements this) should return null for a anonyomous or unauthenticated connection. Lee Flight --RFC4515 extract-- 5.1.1. Anonymous Authentication Mechanism of Simple Bind An LDAP client may use the anonymous authentication mechanism of the simple Bind method to explicitly establish an anonymous authorization state by sending a Bind request with a name value of zero length and specifying the simple authentication choice containing a password value of zero length. 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind An LDAP client may use the unauthenticated authentication mechanism of the simple Bind method to establish an anonymous authorization state by sending a Bind request with a name value (a distinguished name in LDAP string form [RFC4514] of non-zero length) and specifying the simple authentication choice containing a password value of zero length. The distinguished name value provided by the client is intended to be used for trace (e.g., logging) purposes only. The value is not to be authenticated or otherwise validated (including verification that the DN refers to an existing directory object). The value is not to be used (directly or indirectly) for authorization purposes. Unauthenticated Bind operations can have significant security issues (see Section 6.3.1). In particular, users intending to perform Name/Password Authentication may inadvertently provide an empty password and thus cause poorly implemented clients to request Unauthenticated access. 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. Additionally, Servers SHOULD by default fail Unauthenticated Bind requests with a resultCode of unwillingToPerform. -------- > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jef Kazimer > Sent: 29 September 2006 01:53 > To: ActiveDir@mail.activedir.org > Subject: [ActiveDir] ADAM bind Redirection with a NULL password > > Since there has been talk of LDAP "Authentication" as of > late, I figured I'd post my issue of poorly developed > applications allowing a null password to an ADAM instance > using Bind Redirection. > > http://jeftek.spaces.live.com/blog/cns!F2042DC08607EF2!710.entry > > I'd be curious if a bit flip to shut down this possibility > could be put in control of the directory Admin, instead of > relying on the developers. > > Thanks, > > Jef Kazimer > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
