My impression from reading the on-line documentation is that the use of ADAM Proxy Objects and bind redirection is frowned upon anyway.
"Proxy users are designed for special circumstances and should only be used as a last resort, when Windows principals cannot be used directly." and "ADAM bind redirection should be used only in special cases where an application can perform a simple LDAP bind to ADAM but the application still needs to associate the user with a security principal in Active Directory." >From >http://technet2.microsoft.com/WindowsServer/en/library/7cfc8997-bab2-4770-aff2-be424fd03cda1033.mspx?mfr=true Is there no way for the application to use the recommended alternative, i.e. where ADAM receives a SASL bind request and forwards the request to Active Directory? Tony ---------- Original Message ---------------------------------- From: "Jef Kazimer" <[EMAIL PROTECTED]> Reply-To: ActiveDir@mail.activedir.org Date: Thu, 28 Sep 2006 21:17:39 -0500 Eric, The problem stems from lack of ability to modify the application to correct the behavior. If I had the ability to force this, I would simply require null/blank not to be passed to the ADAM server from the application. I've been at odds about the DCR myself, for all the reasons you mentioned. Yet, without the ability to control the applications, the only thing I can control is the directory itself. Without a mechanism to disable such behavior, I am without recourse unfortunately. So far, I've been able to avoid this problem, because the 2 apps I had this happen with, the developer was able to modify the authentication dialog. I have had other apps with other issuers, where modification was not possible. These did not suffer this poor design issue, but I wonder if I will get such an app eventually. I suppose I am just trying to solve a problem, I have not been forced to solve by this method, which means it cane wait. I could go into how it would be nice to have enterprise application minimum standards, and application owners involve infrastructure staff BEFORE an app is purchased, instead of after when it doesn't work, but I won't :) Jef ----- Original Message ----- From: "Eric Fleischman" <[EMAIL PROTECTED]> To: <ActiveDir@mail.activedir.org> Sent: Thursday, September 28, 2006 8:48 PM Subject: RE: [ActiveDir] ADAM bind Redirection with a NULL password One solution would be to ACL all objects such that SELF can read them, then have the app, after it has authenticated as the user, try and read something on the user itself. This way you know you are in fact that user (or someone else that has read access, which presumably won't work as anonymous). In terms of your DCR...could such a bit be put in? I guess. But DCRs that are filed with the intentional intent of going again an RFC typically have a rough time getting through even with a very strong business impact. And you have a workaround already in the app, and another solution I mentioned above. Just setting expectations... ~Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jef Kazimer Sent: Thursday, September 28, 2006 5:53 PM 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 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 ________________________________________________________________ Sent via the WebMail system at mail.activedir.org 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
