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."
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 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
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
