Re: [ActiveDir] ADAM bind Redirection with a NULL password
Do try to push your vendors in the direction of standards-based federation when federation is the solution. It is really the best way to go for that particular class of problems. The real problem for ADFS in the federation space is that it only supports WS-Federation and doesn't support SAML2. A lot of vendors that are interested in federation have already gone down the SAML 2 path, as it has a headstart and a good standards story. It is also non-Microsoft, which makes it instantly interesting to a lot of people, like it or not. One of the things I'm faced with in my own federation deployment is that in order to cover some of the vendors we'll likely need to federate with, I'll need to integrate a completely different product just to support SAML 2.0 protocol. That sucks. I can understand why MS went in the direction they did, but I'd still like to see a SAML 2 compatibility mode or some middleware I could stack on ADFS that would allow me to reuse most of my current investment. We actually considered using a different product that supports both WS-Fed and SAML 2 (Oracle, RSA and Ping all have this for example). The problem is getting the really tight integration with both .NET claims apps and Windows token apps on the inbound scenario side. That's where the ADFS feature set really kicks butt and sort of forces us to use it anyway. Thus, two products. Sigh. Joe K. - Original Message - From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 11:22 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password Tony, I have a workshop next week with a vendor to discuss an extranet solution. Unfortunately, LDAP auth is not going to be possible, since there will be no communication across the firewall. I am steering them toward an ADFS solution, which I think will fit the bill better. The issue will be, that it will require a 3rd party middleware to make work, which I am not sure they will be thrilled about. Thanks for the thoughts on this. Glad to know I'm not the only one struggling with bad apps! ;) Jef 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
RE: [ActiveDir] ADAM bind Redirection with a NULL password
I accept at least partial responsibility for the strong language. I pushed for it as I believed this feature should be used sparingly at the time these docs were written. There were a few things going through my head: 1) First, I was fearful that people simply did simple binds against ADAM in the clear (no SSL) and did not do a threat model. In the all else even case, I'd rather you stay more secure, and it's easier to keep a more secure bind on the table when you use non-simple, as it is typically done at the bind layer and not the connection layer. I am not advocating blind encryption of all connections, merely saying that I know most people don't do threat models and as such I'd take the security in the best guess case. 2) I was also fearful of the mgmt overhead of bind proxy objects. You need to create maintain them, and provisioning is a traditionally non-trivial problem. Adamsync has helped some here, but remember, adamsync did not exist when this language was written. 3) Finally, I was slightly concerned about the auth situation on the box. A proxy bind results in a SID lookup call and a LogonUser() call, and one need assume they go off machine. Just some extra work for ADAM to do rather than other situations which might be more local and less remote work, but the devil is in the details here (what protocol is used, etc.). But the avg case is perhaps better, at least that was my hope. ;) So, that was my rationale. To answer your other question: I have to wonder what is classified as a special circumstances, since I suppose they are all sort of special. I intended special to mean, circumstances where you don't have a better choice. Take that for what it's worth. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 28, 2006 9:12 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password Tony, I have to wonder what is classified as a special circumstances, since I suppose they are all sort of special. I have used Bind Redirection with MIIS/IIFP for quite a few scenarios: Corportate Spinoff: We needed to split off a portion of our users into a new company, and an entirely new forest. To solve the issue of apps only binding to a single NC, we used MIIS to populate an ADAM instance that contained active users from both forests during the TSA. Corporate Acquisitions: Similar situation, where we needed to combine users into a single NC. Having more than 1 user domain, and an app that can ONLY bind to a single Domain/NC. Custom Schema extensions for an application that is not an enterprise class application. You may not want to extend AD for a small subset of users. Extend the ADAM schema for the application, but proxy the user authentication back to the main AD. It also helps with audit and compliance, where you are really only managing a single user principle, but proxying apps to it. Unfortunately, LDAP seems to be the defacto standard for applications. With that, simple bind seems to be the way of choice. I would say, many are Java apps where I think someone wrote a howto many years ago, and I keep seeing the same thing come in as Authentication. Some big name apps from Lotus/IBM, Documentum all have/had issues with only pointing to a single NC, so I don't want to say it's only smaller developers. Many of the companies I've worked at, have had more than a single domain, so I am surprised that so many enterprise apps assume a single NC for authentication. I can't solve the problems at the app level, but I try to solve it at the centralized directory level. Thanks, Jef - Original Message - From: Tony Murray [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 9:27 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password 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-477 0-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
RE: [ActiveDir] ADAM bind Redirection with a NULL password
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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Joe, I have a large Websphere community, which suffers from the single NC for LDAP binds scenario. Have you had any experience with WS and ADFS? The WS guys seem very tight lipped on knowing how to setup WS to work with it. I have been looking at Quests and Netegrity for their ADFS modules for JAVA systems which I think might fit the bill. OUr entire unix platform group is integrated into AD with Quest's VAS product, and surprisingly, they LOVE AD. :) Thanks for the insight, Jef - Original Message - From: Joe Kaplan [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Friday, September 29, 2006 1:16 AM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password Do try to push your vendors in the direction of standards-based federation when federation is the solution. It is really the best way to go for that particular class of problems. The real problem for ADFS in the federation space is that it only supports WS-Federation and doesn't support SAML2. A lot of vendors that are interested in federation have already gone down the SAML 2 path, as it has a headstart and a good standards story. It is also non-Microsoft, which makes it instantly interesting to a lot of people, like it or not. One of the things I'm faced with in my own federation deployment is that in order to cover some of the vendors we'll likely need to federate with, I'll need to integrate a completely different product just to support SAML 2.0 protocol. That sucks. I can understand why MS went in the direction they did, but I'd still like to see a SAML 2 compatibility mode or some middleware I could stack on ADFS that would allow me to reuse most of my current investment. We actually considered using a different product that supports both WS-Fed and SAML 2 (Oracle, RSA and Ping all have this for example). The problem is getting the really tight integration with both .NET claims apps and Windows token apps on the inbound scenario side. That's where the ADFS feature set really kicks butt and sort of forces us to use it anyway. Thus, two products. Sigh. Joe K. - Original Message - From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 11:22 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password Tony, I have a workshop next week with a vendor to discuss an extranet solution. Unfortunately, LDAP auth is not going to be possible, since there will be no communication across the firewall. I am steering them toward an ADFS solution, which I think will fit the bill better. The issue will be, that it will require a 3rd party middleware to make work, which I am not sure they will be thrilled about. Thanks for the thoughts on this. Glad to know I'm not the only one struggling with bad apps! ;) Jef 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Eric, I totally understand and respect the wording that was put in for the ADAM information, and I would agree with leaning toward the cautious side. ADAM itself is only one piece of the puzzle when using proxy Bind, and with all the other services such as MIIS/IIFP and ADAMsync to truly make this work I would definitely classify it as a Special circumstance. If I had not had MIIS experience prior, I would have been overwhelmed with trying to implement that solution, so I can see how it is not something you would want to implement casually. Thanks again, Jef - Original Message - From: Eric Fleischman [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Friday, September 29, 2006 1:22 AM Subject: RE: [ActiveDir] ADAM bind Redirection with a NULL password I accept at least partial responsibility for the strong language. I pushed for it as I believed this feature should be used sparingly at the time these docs were written. There were a few things going through my head: 1) First, I was fearful that people simply did simple binds against ADAM in the clear (no SSL) and did not do a threat model. In the all else even case, I'd rather you stay more secure, and it's easier to keep a more secure bind on the table when you use non-simple, as it is typically done at the bind layer and not the connection layer. I am not advocating blind encryption of all connections, merely saying that I know most people don't do threat models and as such I'd take the security in the best guess case. 2) I was also fearful of the mgmt overhead of bind proxy objects. You need to create maintain them, and provisioning is a traditionally non-trivial problem. Adamsync has helped some here, but remember, adamsync did not exist when this language was written. 3) Finally, I was slightly concerned about the auth situation on the box. A proxy bind results in a SID lookup call and a LogonUser() call, and one need assume they go off machine. Just some extra work for ADAM to do rather than other situations which might be more local and less remote work, but the devil is in the details here (what protocol is used, etc.). But the avg case is perhaps better, at least that was my hope. ;) So, that was my rationale. To answer your other question: I have to wonder what is classified as a special circumstances, since I suppose they are all sort of special. I intended special to mean, circumstances where you don't have a better choice. Take that for what it's worth. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 28, 2006 9:12 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password Tony, I have to wonder what is classified as a special circumstances, since I suppose they are all sort of special. I have used Bind Redirection with MIIS/IIFP for quite a few scenarios: Corportate Spinoff: We needed to split off a portion of our users into a new company, and an entirely new forest. To solve the issue of apps only binding to a single NC, we used MIIS to populate an ADAM instance that contained active users from both forests during the TSA. Corporate Acquisitions: Similar situation, where we needed to combine users into a single NC. Having more than 1 user domain, and an app that can ONLY bind to a single Domain/NC. Custom Schema extensions for an application that is not an enterprise class application. You may not want to extend AD for a small subset of users. Extend the ADAM schema for the application, but proxy the user authentication back to the main AD. It also helps with audit and compliance, where you are really only managing a single user principle, but proxying apps to it. Unfortunately, LDAP seems to be the defacto standard for applications. With that, simple bind seems to be the way of choice. I would say, many are Java apps where I think someone wrote a howto many years ago, and I keep seeing the same thing come in as Authentication. Some big name apps from Lotus/IBM, Documentum all have/had issues with only pointing to a single NC, so I don't want to say it's only smaller developers. Many of the companies I've worked at, have had more than a single domain, so I am surprised that so many enterprise apps assume a single NC for authentication. I can't solve the problems at the app level, but I try to solve it at the centralized directory level. Thanks, Jef - Original Message - From: Tony Murray [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 9:27 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Lee, Thanks for the update on the RFC. I didn't know this was out there. Unfortunately, some of the modifications on the client end you suggested fall into the same bucket. The LDAP applications seem to be written to the most basic of functions, which I've stated earlier. I still have these 3rd party, small developer applications come in that claim to be LDAP and Works with AD!, and I find out they can't support referral chasing, and sometimes don't even support paging. I have had more than 1 app developer ask me if I could up the maxpagesize of the AD for them, because they do not support paging. (We will not) Heh, just yesterday we had to deny an app to use AD, because it REQUIRED many application specific top level OUs to exist in AD, and custom schema extenions. When we inquired to the developer why this was, they didn't know, and that it had not been a problem for other companies they sold this app too. They said they will not work with ADAM either. Thankfully, there is policy to backup that fight for our group, so that we could deny it. Thanks for the update, and I'll be glad to read through this and add it to my ammo bucket for the future :) Jef - Original Message - From: Flight, L. [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Friday, September 29, 2006 5:41 AM Subject: RE: [ActiveDir] ADAM bind Redirection with a NULL password 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Curious about your scenario here Jef. Corportate Spinoff:We needed to split off a portion of our users into a new company, and anentirely new forest. To solve the issue of apps only binding to a single NC, we used MIIS to populate an ADAM instance that contained active usersfrom both forests during the TSA.That seems like a lot of short term work that should be avoided. Since they're spinning off, aren't they, presumably delaying the inevitable separation and not deploying their own version of the app else looking for a different one? That would be time better spent from what I've seen. Just curious though. AlOn 9/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tony,I have to wonder what is classified as a special circumstances, since Isuppose they are all sort of special.I have used Bind Redirection with MIIS/IIFP for quite a few scenarios: Corportate Spinoff:We needed to split off a portion of our users into a new company, and anentirely new forest.To solve the issue of apps only binding to a singleNC, we used MIIS to populate an ADAM instance that contained active users from both forests during the TSA.Corporate Acquisitions:Similar situation, where we needed to combine users into a single NC.Having more than 1 user domain, and an app that can ONLY bind to a single Domain/NC.Custom Schema extensions for an application that is not an enterprise classapplication. You may not want to extend AD for a small subset of users.Extend the ADAM schema for the application, but proxy the user authentication back to the main AD.It also helps with audit and compliance, where you are really only managinga single user principle, but proxying apps to it.Unfortunately, LDAP seems to be the defacto standard for applications.With that, simple bind seems to be the way of choice. I would say, many areJava apps where I think someone wrote a howto many years ago, and I keepseeing the same thing come in as Authentication. Some big name apps from Lotus/IBM, Documentum all have/had issues with onlypointing to a single NC, so I don't want to say it's only smallerdevelopers.Many of the companies I've worked at, have had more than a single domain, so I am surprised that so many enterprise apps assume asingle NC for authentication.I can't solve the problems at the app level, but I try to solve it at thecentralized directory level. Thanks,Jef- Original Message -From: Tony Murray [EMAIL PROTECTED]To: ActiveDir@mail.activedir.orgSent: Thursday, September 28, 2006 9:27 PMSubject: Re: [ActiveDir] ADAM bind Redirection with a NULL password 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Al, It was a 2 year integration until separation, which wasn't exactly short term. During that time, there were still shared projects between the old and the new organizations, with shared data that needed to be accessed by both. it is easy for the apps that could be cut over, but that 2 year integration did not allow that for all apps. To be honest, looking back, this was a very simple project to implement from a technical standpoint using MIIS and ADAM. If I get a chance, I'll try and write up the public details, and maybe it would be clearer to understand how/why this was done. Thanks, Jef - Original Message - From: Al Mulnick To: ActiveDir@mail.activedir.org Sent: Friday, September 29, 2006 9:47 AM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password Curious about your scenario here Jef. Corportate Spinoff:We needed to split off a portion of our users into a new company, and anentirely new forest. To solve the issue of apps only binding to a single NC, we used MIIS to populate an ADAM instance that contained active usersfrom both forests during the TSA.That seems like a lot of short term work that should be avoided. Since they're spinning off, aren't they, presumably delaying the inevitable separation and not deploying their own version of the app else looking for a different one? That would be time better spent from what I've seen. Just curious though. Al On 9/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tony,I have to wonder what is classified as a "special circumstances", since Isuppose they are all sort of special.I have used Bind Redirection with MIIS/IIFP for quite a few scenarios:Corportate Spinoff:We needed to split off a portion of our users into a new company, and anentirely new forest.To solve the issue of apps only binding to a singleNC, we used MIIS to populate an ADAM instance that contained active users from both forests during the TSA.Corporate Acquisitions:Similar situation, where we needed to combine users into a single NC.Having more than 1 user domain, and an app that can ONLY bind to a single Domain/NC.Custom Schema extensions for an application that is not an enterprise classapplication. You may not want to extend AD for a small subset of users.Extend the ADAM schema for the application, but proxy the user authentication back to the main AD.It also helps with audit and compliance, where you are really only managinga single user principle, but proxying apps to it.Unfortunately, LDAP seems to be the defacto standard for applications.With that, simple bind seems to be the way of choice. I would say, many areJava apps where I think someone wrote a "howto" many years ago, and I keepseeing the same thing come in as "Authentication". Some big name apps from Lotus/IBM, Documentum all have/had issues with onlypointing to a single NC, so I don't want to say it's only smallerdevelopers.Many of the companies I've worked at, have had more than a single domain, so I am surprised that so many "enterprise" apps assume asingle NC for authentication.I can't solve the problems at the app level, but I try to solve it at thecentralized directory level. Thanks,Jef- Original Message -From: "Tony Murray" [EMAIL PROTECTED]To: ActiveDir@mail.activedir.orgSent: Thursday, September 28, 2006 9:27 PMSubject: Re: [ActiveDir] ADAM bind Redirection with a NULL password 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.microsoftcom/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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Ah, one of those eh? I'd be interested to see the public details if you get the chance. On 9/29/06, Jef Kazimer [EMAIL PROTECTED] wrote: Al, It was a 2 year integration until separation, which wasn't exactly short term. During that time, there were still shared projects between the old and the new organizations, with shared data that needed to be accessed by both. it is easy for the apps that could be cut over, but that 2 year integration did not allow that for all apps. To be honest, looking back, this was a very simple project to implement from a technical standpoint using MIIS and ADAM. If I get a chance, I'll try and write up the public details, and maybe it would be clearer to understand how/why this was done. Thanks, Jef - Original Message - From: Al Mulnick To: ActiveDir@mail.activedir.org Sent: Friday, September 29, 2006 9:47 AM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password Curious about your scenario here Jef. Corportate Spinoff:We needed to split off a portion of our users into a new company, and anentirely new forest. To solve the issue of apps only binding to a single NC, we used MIIS to populate an ADAM instance that contained active usersfrom both forests during the TSA.That seems like a lot of short term work that should be avoided. Since they're spinning off, aren't they, presumably delaying the inevitable separation and not deploying their own version of the app else looking for a different one? That would be time better spent from what I've seen. Just curious though. Al On 9/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tony,I have to wonder what is classified as a special circumstances, since Isuppose they are all sort of special.I have used Bind Redirection with MIIS/IIFP for quite a few scenarios:Corportate Spinoff:We needed to split off a portion of our users into a new company, and anentirely new forest.To solve the issue of apps only binding to a singleNC, we used MIIS to populate an ADAM instance that contained active users from both forests during the TSA.Corporate Acquisitions:Similar situation, where we needed to combine users into a single NC.Having more than 1 user domain, and an app that can ONLY bind to a single Domain/NC.Custom Schema extensions for an application that is not an enterprise classapplication. You may not want to extend AD for a small subset of users.Extend the ADAM schema for the application, but proxy the user authentication back to the main AD.It also helps with audit and compliance, where you are really only managinga single user principle, but proxying apps to it.Unfortunately, LDAP seems to be the defacto standard for applications.With that, simple bind seems to be the way of choice. I would say, many areJava apps where I think someone wrote a howto many years ago, and I keepseeing the same thing come in as Authentication. Some big name apps from Lotus/IBM, Documentum all have/had issues with onlypointing to a single NC, so I don't want to say it's only smallerdevelopers.Many of the companies I've worked at, have had more than a single domain, so I am surprised that so many enterprise apps assume asingle NC for authentication.I can't solve the problems at the app level, but I try to solve it at thecentralized directory level. Thanks,Jef- Original Message -From: Tony Murray [EMAIL PROTECTED]To: ActiveDir@mail.activedir.orgSent: Thursday, September 28, 2006 9:27 PMSubject: Re: [ActiveDir] ADAM bind Redirection with a NULL password 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.microsoftcom/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
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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
It is a good article with good analysis. I do think it would be a useful feature to have a bit to flip for simple bind to be forced to fail with blank password, even though this would go against the RFC spec. I also think it is interesting that since ADAM is actually doing some sort of secure authentication to AD, this bind attempt does actually up the bad pwd count and can result in user lockout. Another scenario that is interesting with blank passwords is that potentially an ADAM or AD user could have an actual blank password. It then becomes very difficult to tell them apart from a bind attempt. I remember Dmitri discussing this on the newsgroups a ways back, although as I recall, he seemed to believe this was an inevitable consequence of the spec. Besides the DCR, I think all you can do is validate on the application side (but you already knew that). Joe K. - Original Message - From: Jef Kazimer [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 7:53 PM 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Joe, I forgot to mention on the article (Which I updated): - I forgot to mention, I had thought to myself Did I somehow enable anonymous binds and forget?, since part of the design was to not-allow anonymous. I did check the config entry as outlined in the ADAM FAQ: ADAM does not accept anonymous bind requests by default. To enable anonymous LDAP operations in ADAM, you must set the seventh character of the dsHeuristics value to 2. This indeed was set to NOT allow anonymous binds, which based on the wording I would assume mean that anonymous binds would be rejected. In actuality, an anonymous bind is a SUCCESS, but you can't enumerate the directory structure from that point on. Perhaps the wording should be changed to reflect this? - Original Message - From: Joe Kaplan [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 8:58 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password It is a good article with good analysis. I do think it would be a useful feature to have a bit to flip for simple bind to be forced to fail with blank password, even though this would go against the RFC spec. I also think it is interesting that since ADAM is actually doing some sort of secure authentication to AD, this bind attempt does actually up the bad pwd count and can result in user lockout. Another scenario that is interesting with blank passwords is that potentially an ADAM or AD user could have an actual blank password. It then becomes very difficult to tell them apart from a bind attempt. I remember Dmitri discussing this on the newsgroups a ways back, although as I recall, he seemed to believe this was an inevitable consequence of the spec. Besides the DCR, I think all you can do is validate on the application side (but you already knew that). Joe K. - Original Message - From: Jef Kazimer [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 7:53 PM 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
The problem is that this happens a lot. There are simply tons of applications out there that don't use Windows SASL binds. It would be nice if it wasn't this way, but that's the reality of LDAP auth, especially with vendors that don't use Microsoft's LDAP libraries. I've got at least 6 of these at work right now. The other thing that is hard to deal with is scenarios where you have a mix of ADAM and AD principals. Since it isn't easy to tell apart ADAM from AD principals except for possibly by naming convention, so it can be hard to know whether an app should do a simple or SASL bind for a given user in this use case. So, the advice from MS is good, but not easy to follow. Also, the feature is there to be used. Another thing is that to use features like Fast Concurrent Bind, you have to do simple bind. It isn't supported with SASL. BTW, does FCB work with bind proxies? I've never tried. Joe K. - Original Message - From: Tony Murray [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 9:27 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
I agree, the documentation is misleading. They should say that anonymous searches aren't allowed. Joe K. - Original Message - From: Jef Kazimer [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 9:24 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password Joe, I forgot to mention on the article (Which I updated): - I forgot to mention, I had thought to myself Did I somehow enable anonymous binds and forget?, since part of the design was to not-allow anonymous. I did check the config entry as outlined in the ADAM FAQ: ADAM does not accept anonymous bind requests by default. To enable anonymous LDAP operations in ADAM, you must set the seventh character of the dsHeuristics value to 2. This indeed was set to NOT allow anonymous binds, which based on the wording I would assume mean that anonymous binds would be rejected. In actuality, an anonymous bind is a SUCCESS, but you can't enumerate the directory structure from that point on. Perhaps the wording should be changed to reflect this? 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Yes, I can see that Windows SASL binds might not be universally available ;-) Thinking about it, another problem with the SASL binds is that presumably the ADAM instance must be running on a server that is a member of the authenticating AD domain (or at least one that has a trust back to the authenticating domain). This would limit it's usefulness in extranet scenarios because of the ports that would have to be opened between ADAM and AD (assuming they are on opposite sides of a firewall). Tony -- Original Message -- From: Joe Kaplan [EMAIL PROTECTED] Reply-To: ActiveDir@mail.activedir.org Date: Thu, 28 Sep 2006 22:12:34 -0500 The problem is that this happens a lot. There are simply tons of applications out there that don't use Windows SASL binds. It would be nice if it wasn't this way, but that's the reality of LDAP auth, especially with vendors that don't use Microsoft's LDAP libraries. I've got at least 6 of these at work right now. The other thing that is hard to deal with is scenarios where you have a mix of ADAM and AD principals. Since it isn't easy to tell apart ADAM from AD principals except for possibly by naming convention, so it can be hard to know whether an app should do a simple or SASL bind for a given user in this use case. So, the advice from MS is good, but not easy to follow. Also, the feature is there to be used. Another thing is that to use features like Fast Concurrent Bind, you have to do simple bind. It isn't supported with SASL. BTW, does FCB work with bind proxies? I've never tried. Joe K. - Original Message - From: Tony Murray [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 9:27 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Tony, I have to wonder what is classified as a special circumstances, since I suppose they are all sort of special. I have used Bind Redirection with MIIS/IIFP for quite a few scenarios: Corportate Spinoff: We needed to split off a portion of our users into a new company, and an entirely new forest. To solve the issue of apps only binding to a single NC, we used MIIS to populate an ADAM instance that contained active users from both forests during the TSA. Corporate Acquisitions: Similar situation, where we needed to combine users into a single NC. Having more than 1 user domain, and an app that can ONLY bind to a single Domain/NC. Custom Schema extensions for an application that is not an enterprise class application. You may not want to extend AD for a small subset of users. Extend the ADAM schema for the application, but proxy the user authentication back to the main AD. It also helps with audit and compliance, where you are really only managing a single user principle, but proxying apps to it. Unfortunately, LDAP seems to be the defacto standard for applications. With that, simple bind seems to be the way of choice. I would say, many are Java apps where I think someone wrote a howto many years ago, and I keep seeing the same thing come in as Authentication. Some big name apps from Lotus/IBM, Documentum all have/had issues with only pointing to a single NC, so I don't want to say it's only smaller developers. Many of the companies I've worked at, have had more than a single domain, so I am surprised that so many enterprise apps assume a single NC for authentication. I can't solve the problems at the app level, but I try to solve it at the centralized directory level. Thanks, Jef - Original Message - From: Tony Murray [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 9:27 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Joe, FCB works with simple binds, and BR ONLY works with simple binds, so I suppose it's possible. I've never coded to try however, but I could check it out. Jef - Original Message - From: Joe Kaplan [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 10:12 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password The problem is that this happens a lot. There are simply tons of applications out there that don't use Windows SASL binds. It would be nice if it wasn't this way, but that's the reality of LDAP auth, especially with vendors that don't use Microsoft's LDAP libraries. I've got at least 6 of these at work right now. The other thing that is hard to deal with is scenarios where you have a mix of ADAM and AD principals. Since it isn't easy to tell apart ADAM from AD principals except for possibly by naming convention, so it can be hard to know whether an app should do a simple or SASL bind for a given user in this use case. So, the advice from MS is good, but not easy to follow. Also, the feature is there to be used. Another thing is that to use features like Fast Concurrent Bind, you have to do simple bind. It isn't supported with SASL. BTW, does FCB work with bind proxies? I've never tried. Joe K. - Original Message - From: Tony Murray [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 9:27 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Tony, I have a workshop next week with a vendor to discuss an extranet solution. Unfortunately, LDAP auth is not going to be possible, since there will be no communication across the firewall. I am steering them toward an ADFS solution, which I think will fit the bill better. The issue will be, that it will require a 3rd party middleware to make work, which I am not sure they will be thrilled about. Thanks for the thoughts on this. Glad to know I'm not the only one struggling with bad apps! ;) Jef - Original Message - From: Tony Murray [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 10:57 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password Yes, I can see that Windows SASL binds might not be universally available ;-) Thinking about it, another problem with the SASL binds is that presumably the ADAM instance must be running on a server that is a member of the authenticating AD domain (or at least one that has a trust back to the authenticating domain). This would limit it's usefulness in extranet scenarios because of the ports that would have to be opened between ADAM and AD (assuming they are on opposite sides of a firewall). Tony -- Original Message -- From: Joe Kaplan [EMAIL PROTECTED] Reply-To: ActiveDir@mail.activedir.org Date: Thu, 28 Sep 2006 22:12:34 -0500 The problem is that this happens a lot. There are simply tons of applications out there that don't use Windows SASL binds. It would be nice if it wasn't this way, but that's the reality of LDAP auth, especially with vendors that don't use Microsoft's LDAP libraries. I've got at least 6 of these at work right now. The other thing that is hard to deal with is scenarios where you have a mix of ADAM and AD principals. Since it isn't easy to tell apart ADAM from AD principals except for possibly by naming convention, so it can be hard to know whether an app should do a simple or SASL bind for a given user in this use case. So, the advice from MS is good, but not easy to follow. Also, the feature is there to be used. Another thing is that to use features like Fast Concurrent Bind, you have to do simple bind. It isn't supported with SASL. BTW, does FCB work with bind proxies? I've never tried. Joe K. - Original Message - From: Tony Murray [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 9:27 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password 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
Re: [ActiveDir] ADAM bind Redirection with a NULL password
Yep, that's definitely true, although domain membership is also required to do bind proxy auth as well. In a lot of these scenarios, the firewall is configured so that only LDAP ports are open to ADAM from the application, but the ADAM server has the necessary firewall ports open for domain membership. In some cases, ADAM can actually go inside the DMZ, with just the app server in the DMZ. There are lots of options. :) There are so many useful scenarios for Microsoft app servers that essentially require Internet facing web servers to be domain members (SharePoint, etc.) that I'm guessing people are used to opening domain membership ports through the DMZ firewall anyway. I'm embarassed to admit that we have numerous holes in our firewalls allowing third parties to hit our DCs directly via LDAP for auth (SSL LDAP, yes, but still LDAP). Sure, the firewall rules only allow traffic from specific IP addresses, but it is still way icky. One of the reasons I'm so interested in ADFS is to help stomp out these monstrosities as soon as possible, but it will take a long time before all the vendors support federation, all the scenarios are covered and we actually have the IT budgeting priorities in place to make the necessary changes on our end. Joe K. - Original Message - From: Tony Murray [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 10:57 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password Yes, I can see that Windows SASL binds might not be universally available ;-) Thinking about it, another problem with the SASL binds is that presumably the ADAM instance must be running on a server that is a member of the authenticating AD domain (or at least one that has a trust back to the authenticating domain). This would limit it's usefulness in extranet scenarios because of the ports that would have to be opened between ADAM and AD (assuming they are on opposite sides of a firewall). Tony -- Original Message -- From: Joe Kaplan [EMAIL PROTECTED] Reply-To: ActiveDir@mail.activedir.org Date: Thu, 28 Sep 2006 22:12:34 -0500 The problem is that this happens a lot. There are simply tons of applications out there that don't use Windows SASL binds. It would be nice if it wasn't this way, but that's the reality of LDAP auth, especially with vendors that don't use Microsoft's LDAP libraries. I've got at least 6 of these at work right now. The other thing that is hard to deal with is scenarios where you have a mix of ADAM and AD principals. Since it isn't easy to tell apart ADAM from AD principals except for possibly by naming convention, so it can be hard to know whether an app should do a simple or SASL bind for a given user in this use case. So, the advice from MS is good, but not easy to follow. Also, the feature is there to be used. Another thing is that to use features like Fast Concurrent Bind, you have to do simple bind. It isn't supported with SASL. BTW, does FCB work with bind proxies? I've never tried. Joe K. - Original Message - From: Tony Murray [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, September 28, 2006 9:27 PM Subject: Re: [ActiveDir] ADAM bind Redirection with a NULL password 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
