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,
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
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
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
