Re: [ActiveDir]SUBDOMAIN AND LDAP
Ramon Linan wrote: It looks like this guys that are building the app are using LDAP to find the username and Kerberos to create the token, do that make sense? Also, it looks like this application add 2 classes to the AD, I wonder when is worthy to use ADAM , should it be use for any custom app that expands the schema or only depending on how "big" the changes are to the schema? Extending the schema is not the end of the world and it is standard operation in AD, but it has to be done with knowledge and caution. They have to get proper OIDs for their extensions and they should have unique names for their classes and attributes. Extending the schema is not a reason to use ADAM instead of extending AD schema. Using ADAM can bu justified by other reasons but we don't know many things about your organization and this application to make statement use or not to use ADAM\AD. -- Tomasz Onyszko http://www.w2k.pl/ - (PL) http://blogs.dirteam.com/blogs/tomek/ - (EN) 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]SUBDOMAIN AND LDAP
It looks like this guys that are building the app are using LDAP to find the username and Kerberos to create the token, do that make sense? Also, it looks like this application add 2 classes to the AD, I wonder when is worthy to use ADAM , should it be use for any custom app that expands the schema or only depending on how "big" the changes are to the schema? Any recommendation? Thanks Rezuma -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Onyszko Sent: Monday, September 25, 2006 10:20 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP Ramon Linan wrote: > You guys are amazing, in terms of AD knowledge, way out of league. > Anyway, I was the one asking about this application, I have more > questions. > > First I must said, that I am waiting to hear from the vendor about > whether the app modifies the Schema or not, I got 2 emails from them, > one saying yes and the other saying no, it does not change it!!! :( I > am panicking already. > > Here goes my question: > We have 2 offices, only 4 people in the HQ are going to be using this > app, so if the app changes the schema of AD it would be better to use > ADAM, is this right? Especially because I don't know how good if the > application going to be about cleaning AD if we don't use it anymore. If we are talking about "cleaning" as about "cleaning" schema this can't be done - You can't remove classes or attributes from schema, You can only defunct them in Windows 2003. > > The first vendor tech who replied to me said that the application > changes the schema, and he was saying that it has already changed the > schema in the submain, where all the current users for this > application are, is that possible? If I have domain.com and > child.domain.com, can I You should really consider using their application as obviously they don't have basic AD knowledge or they are missing some concepts. Schema is common for all domains in the forest, so If You will alter the schema on schema master all domains in the forest will get this changes. BTW to alter the schema You have to have really high privileges so: 1. Somebody let them to do something with schema admin privileges 2. They don't know what they are talking about. > change the schema of AD for a subdomain and not for the main domain?? > I though It was only one LDAP for the whole forest?, this does not > make sense considering the schema owner is the same for both child and > main domain. Can I say to the vendor how wrong he is or are there > exception to that situation? You should ask them: 1. If their application is extending AD schema 2. If answer to 1 is Yes: do they have their specific OIDs numbers registered and they are unique. 3. They should present You these changes as LDIFs and You should test it in the lab. > > If there a tool I can use that will compare the out of the box schema > for windows 2003+exchange with the current schema? Or do I have to use > adsiedit and try to figure out what is part of the app? Schema Analyzer which comes with ADAM SP1 can do this: http://www.microsoft.com/downloads/details.aspx?FamilyId=9688F8B9-1034-4 EF6-A3E5-2A2A57B5C8E4&displaylang=en > I am still waiting to receive an answer about the way these dudes > authenticate, simple bind, secure bind, Kerberos, or whatever. -- Tomasz Onyszko http://www.w2k.pl/ - (PL) http://blogs.dirteam.com/blogs/tomek/ - (EN) 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]SUBDOMAIN AND LDAP
I see, thanks for the info, especially about not being able to delete classes or properties, this actually make even more useful using ADAM, since there are app that will not longer use in a few years, cool stuff all this. Good point, I just checked, and only the administrator user is part of the schema group , they don't have the administrator user or password so probably they aren't change the schema at all. Thanks for the info again. Rezuma -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Onyszko Sent: Monday, September 25, 2006 10:20 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP Ramon Linan wrote: > You guys are amazing, in terms of AD knowledge, way out of league. > Anyway, I was the one asking about this application, I have more > questions. > > First I must said, that I am waiting to hear from the vendor about > whether the app modifies the Schema or not, I got 2 emails from them, > one saying yes and the other saying no, it does not change it!!! :( I > am panicking already. > > Here goes my question: > We have 2 offices, only 4 people in the HQ are going to be using this > app, so if the app changes the schema of AD it would be better to use > ADAM, is this right? Especially because I don't know how good if the > application going to be about cleaning AD if we don't use it anymore. If we are talking about "cleaning" as about "cleaning" schema this can't be done - You can't remove classes or attributes from schema, You can only defunct them in Windows 2003. > > The first vendor tech who replied to me said that the application > changes the schema, and he was saying that it has already changed the > schema in the submain, where all the current users for this > application are, is that possible? If I have domain.com and > child.domain.com, can I You should really consider using their application as obviously they don't have basic AD knowledge or they are missing some concepts. Schema is common for all domains in the forest, so If You will alter the schema on schema master all domains in the forest will get this changes. BTW to alter the schema You have to have really high privileges so: 1. Somebody let them to do something with schema admin privileges 2. They don't know what they are talking about. > change the schema of AD for a subdomain and not for the main domain?? > I though It was only one LDAP for the whole forest?, this does not > make sense considering the schema owner is the same for both child and > main domain. Can I say to the vendor how wrong he is or are there > exception to that situation? You should ask them: 1. If their application is extending AD schema 2. If answer to 1 is Yes: do they have their specific OIDs numbers registered and they are unique. 3. They should present You these changes as LDIFs and You should test it in the lab. > > If there a tool I can use that will compare the out of the box schema > for windows 2003+exchange with the current schema? Or do I have to use > adsiedit and try to figure out what is part of the app? Schema Analyzer which comes with ADAM SP1 can do this: http://www.microsoft.com/downloads/details.aspx?FamilyId=9688F8B9-1034-4 EF6-A3E5-2A2A57B5C8E4&displaylang=en > I am still waiting to receive an answer about the way these dudes > authenticate, simple bind, secure bind, Kerberos, or whatever. -- Tomasz Onyszko http://www.w2k.pl/ - (PL) http://blogs.dirteam.com/blogs/tomek/ - (EN) 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]SUBDOMAIN AND LDAP
Ramon Linan wrote: You guys are amazing, in terms of AD knowledge, way out of league. Anyway, I was the one asking about this application, I have more questions. First I must said, that I am waiting to hear from the vendor about whether the app modifies the Schema or not, I got 2 emails from them, one saying yes and the other saying no, it does not change it!!! :( I am panicking already. Here goes my question: We have 2 offices, only 4 people in the HQ are going to be using this app, so if the app changes the schema of AD it would be better to use ADAM, is this right? Especially because I don't know how good if the application going to be about cleaning AD if we don't use it anymore. If we are talking about "cleaning" as about "cleaning" schema this can't be done - You can't remove classes or attributes from schema, You can only defunct them in Windows 2003. The first vendor tech who replied to me said that the application changes the schema, and he was saying that it has already changed the schema in the submain, where all the current users for this application are, is that possible? If I have domain.com and child.domain.com, can I You should really consider using their application as obviously they don't have basic AD knowledge or they are missing some concepts. Schema is common for all domains in the forest, so If You will alter the schema on schema master all domains in the forest will get this changes. BTW to alter the schema You have to have really high privileges so: 1. Somebody let them to do something with schema admin privileges 2. They don't know what they are talking about. change the schema of AD for a subdomain and not for the main domain?? I though It was only one LDAP for the whole forest?, this does not make sense considering the schema owner is the same for both child and main domain. Can I say to the vendor how wrong he is or are there exception to that situation? You should ask them: 1. If their application is extending AD schema 2. If answer to 1 is Yes: do they have their specific OIDs numbers registered and they are unique. 3. They should present You these changes as LDIFs and You should test it in the lab. If there a tool I can use that will compare the out of the box schema for windows 2003+exchange with the current schema? Or do I have to use adsiedit and try to figure out what is part of the app? Schema Analyzer which comes with ADAM SP1 can do this: http://www.microsoft.com/downloads/details.aspx?FamilyId=9688F8B9-1034-4EF6-A3E5-2A2A57B5C8E4&displaylang=en I am still waiting to receive an answer about the way these dudes authenticate, simple bind, secure bind, Kerberos, or whatever. -- Tomasz Onyszko http://www.w2k.pl/ - (PL) http://blogs.dirteam.com/blogs/tomek/ - (EN) 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]SUBDOMAIN AND LDAP
You guys are amazing, in terms of AD knowledge, way out of league. Anyway, I was the one asking about this application, I have more questions. First I must said, that I am waiting to hear from the vendor about whether the app modifies the Schema or not, I got 2 emails from them, one saying yes and the other saying no, it does not change it!!! :( I am panicking already. Here goes my question: We have 2 offices, only 4 people in the HQ are going to be using this app, so if the app changes the schema of AD it would be better to use ADAM, is this right? Especially because I don't know how good if the application going to be about cleaning AD if we don't use it anymore. The first vendor tech who replied to me said that the application changes the schema, and he was saying that it has already changed the schema in the submain, where all the current users for this application are, is that possible? If I have domain.com and child.domain.com, can I change the schema of AD for a subdomain and not for the main domain?? I though It was only one LDAP for the whole forest?, this does not make sense considering the schema owner is the same for both child and main domain. Can I say to the vendor how wrong he is or are there exception to that situation? If there a tool I can use that will compare the out of the box schema for windows 2003+exchange with the current schema? Or do I have to use adsiedit and try to figure out what is part of the app? I am still waiting to receive an answer about the way these dudes authenticate, simple bind, secure bind, Kerberos, or whatever. Thanks all -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Sunday, September 24, 2006 4:34 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP In my own mind I've wrestled a lot with whether or not I like auth via LDAP. I've come to the conclusion that it's ok, and that we should build mechanisms to facilitate it. Things like tokenGroups on RootDSE speak to this, but we should do more. LDAP is easy. Anyone can write an LDAP-based application. On the flip side, Kerb is hard (a-la ADFS). Windows-level integration (LogonUser() like APIs) is likely what I like best, but there are problems, such as lack of x-platform story and the need to be within trust's reach. ADFS is a pretty good answer, but it's new, and people aren't yet comfy with the APIs (assuming they are easy to use, like LDAP) as well as lack of a consistent, reliable infrastructure you find everywhere. LDAP is the defector choice considering these complications. So, you can like LDAP or not, but it's here to stay and people are using it. :) And I'm not sure this is a bad thing. On some specific points > Far too many times that I have looked at LDAP traces I see passwords > and IDs just flowing across the wire like there was no tomorrow. To be fair, you need to be clear as to where you are seeing this. For example, two servers talking to one another in the clear might be acceptable depending upon your security model. SSL does not raise the bar out of the gate like people seem to want to believe. You need to look at a threat model to really know. In fact, I'd assert that most people who turn on SSL do so straight out of the gate and take the perf hit w/o ever having looked at a threat model! This is sad to me, it means they didn't threat model generally (and consequently don't know where the real gaps are) but also are paying a perf penalty w/o really knowing if it is required. > Is your thought that those protocols are headed in the direction to be > more universal and used even when Web access isn't even involved? I don't know what Joe was thinking, but I'm certainly willing to assert this. As these technologies become easier to use and empower more scenarios, it is reasonable to assume that people may use them internally as well as externally. As this happens, it is rolled out even within an organization. I can name a few major organizations off hand which are using these as a unifying infrastructure among desperate systems within their enterprise. It is likely going to happen more and more, and I think it's already happening quite a bit today. That said, this is not to say you will see 100% coverageI don't know. If we make ADFS a Kerberos-like piece of the infrastructure (automagically installed and configured out of the box), that becomes a more realistic perspective to consider. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, September 24, 2006 8:10 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP Yeah I understand, lots of vendors use LDAP for auth, but it doesn't make it good/right. Just like lots of vendors requiring admin access or always passing NULL for LPSECURITY_
RE: [ActiveDir]SUBDOMAIN AND LDAP
In my own mind I've wrestled a lot with whether or not I like auth via LDAP. I've come to the conclusion that it's ok, and that we should build mechanisms to facilitate it. Things like tokenGroups on RootDSE speak to this, but we should do more. LDAP is easy. Anyone can write an LDAP-based application. On the flip side, Kerb is hard (a-la ADFS). Windows-level integration (LogonUser() like APIs) is likely what I like best, but there are problems, such as lack of x-platform story and the need to be within trust's reach. ADFS is a pretty good answer, but it's new, and people aren't yet comfy with the APIs (assuming they are easy to use, like LDAP) as well as lack of a consistent, reliable infrastructure you find everywhere. LDAP is the defector choice considering these complications. So, you can like LDAP or not, but it's here to stay and people are using it. :) And I'm not sure this is a bad thing. On some specific points > Far too many times that I have looked at LDAP traces I see passwords > and IDs just flowing across the wire like there was no tomorrow. To be fair, you need to be clear as to where you are seeing this. For example, two servers talking to one another in the clear might be acceptable depending upon your security model. SSL does not raise the bar out of the gate like people seem to want to believe. You need to look at a threat model to really know. In fact, I'd assert that most people who turn on SSL do so straight out of the gate and take the perf hit w/o ever having looked at a threat model! This is sad to me, it means they didn't threat model generally (and consequently don't know where the real gaps are) but also are paying a perf penalty w/o really knowing if it is required. > Is your thought that those protocols are headed in the direction > to be more universal and used even when Web access isn't even involved? I don't know what Joe was thinking, but I'm certainly willing to assert this. As these technologies become easier to use and empower more scenarios, it is reasonable to assume that people may use them internally as well as externally. As this happens, it is rolled out even within an organization. I can name a few major organizations off hand which are using these as a unifying infrastructure among desperate systems within their enterprise. It is likely going to happen more and more, and I think it's already happening quite a bit today. That said, this is not to say you will see 100% coverageI don't know. If we make ADFS a Kerberos-like piece of the infrastructure (automagically installed and configured out of the box), that becomes a more realistic perspective to consider. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, September 24, 2006 8:10 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP Yeah I understand, lots of vendors use LDAP for auth, but it doesn't make it good/right. Just like lots of vendors requiring admin access or always passing NULL for LPSECURITY_ATTRIBUTES when working with securable objects. ADAM is another story, if you need to use ADAM principals you are stuck with using LDAP for the auth. I still don't like it though. :) Of course you are correct on the using SSL can help beef up the security but that seems to be done in the minority of the cases. Far too many times that I have looked at LDAP traces I see passwords and IDs just flowing across the wire like there was no tomorrow. The thing is most of the users I expect have no clue that they are being exposed in such a way because they trust that the Administrators and vendors actually know what they are doing. Course this is the case with many web based apps as well, but folks have started to learn to mistrust these automatically as time goes by. The little "key" on the browser helps a little but it tells you nothing about the backend and how insecure it is. I guess a possible configuration to help with this would be to configure IPSEC to only allow port 389/3268 to be used by replication partners. This would probably just break a ton of other stuff including anything using say kerberos/ntlm LDAP packet encryption or TSL as well as all of the non-secured stuff. As for the WS-* stuff, this is obviously more prevalent than just Web related techs. I admit to being completely uninformed on those protocols. Is your thought that those protocols are headed in the direction to be more universal and used even when Web access isn't even involved? joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan Sent: Saturday, September 23, 2006 12:15 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP Although a do tend
Re: [ActiveDir]SUBDOMAIN AND LDAP
Eric Fleischman wrote: (...) I will jump here a little On the SSL front, it's interesting that you see this as a strength of ADFS. I would argue the opposite. Cert infrastructures are non-trivial AFAIK ADFS at current stage doesn't full implement WS-Security and thus we have to use SSL for all communication between ADFS parties. Element we are missing in this puzzle from WS-Security is SOAP messages encryption. But this is only from transport security point of view. to configure or maintain, I always saw it as a downside to ADFS that it requires one to get a PhD is certology and make this work not only for you but across organizations, assuming you use it in this way. Of course, the real solution to all of this is making a cert infrastructure as easy to run as, say, the key infrastructure that makes Kerberos "just work" for you. Yes, Eric You are right that configuring ADFS and all this cert stuff is a pain in ... for most of people, but with only basic understanding of PKI and good documentation reading this can be configured for ADFS in few minutes (of course if you have proper certs). I think that making it more "usable", maybe through enabling auto enrollment for ADFS servers will make it better. -- Tomasz Onyszko http://www.w2k.pl/ - (PL) http://blogs.dirteam.com/blogs/tomek/ - (EN) 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]SUBDOMAIN AND LDAP
Yes, we should file a bug for AD. I'll take this offline with you.
On the SSL front, it's interesting that you see this as a strength of
ADFS. I would argue the opposite. Cert infrastructures are non-trivial
to configure or maintain, I always saw it as a downside to ADFS that it
requires one to get a PhD is certology and make this work not only for
you but across organizations, assuming you use it in this way.
Of course, the real solution to all of this is making a cert
infrastructure as easy to run as, say, the key infrastructure that makes
Kerberos "just work" for you.
~Eric
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan
Sent: Sunday, September 24, 2006 10:49 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP
That's very cool, Eric. I had no idea that setting existed in ADAM.
Any
change of sneaking that into the AD stack?
I agree that it only solves half the problem, but at least by preventing
this from working at all, it keeps people from setting up apps that will
do
unsecure simple binds thousands of times per day for years. There is
only
so much you can do.
I also agree that SSL just isn't that easy and can't be, just because of
the
way it works. That doesn't stop me from wishing it was. :) One thing I
like about ADFS is that you have to use SSL to play, so you can't even
get
yourself in trouble.
I'll definitely file a bug on the audit thing. I think that would be
nice,
even with ADAM in the mode to reject insecure simple binds, because you
could find out which clients are attempting it.
Joe K.
- Original Message -
From: "Eric Fleischman" <[EMAIL PROTECTED]>
To:
Sent: Sunday, September 24, 2006 11:48 AM
Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP
> I'd love to see an AD and ADAM option that would allow the DS to
> reject simple bind operations on non-SSL ports
We agree. That's why we built it in to the product. :) Well, in to ADAM
that is.
See object CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,CN={}. Check out the attribute
msds-other-settings, value named RequireSecureSimpleBind=0. Change that
0 to a 1, then you have enabled the protection.
I would point out, this does not prevent a client from *presenting* a
password via simple bind w/o connection security, only from the
operation succeeding. So you could still present a password (thereby
showing it to an attacker), it's just that it won't work. This is
training with the stick, not the carrot.
It's akin to saying, I can protect your SSN from working when you scream
it to me in a room full of people (ie, require you write it on a piece
of paper and pass it over), but I can't stop you from screaming, only
punish you when you make this bad choice.
> Another thing that would be helpful would be an unencrypted simple
bind
> audit event that could be configured, so that you could find the IP
> address of any client issuing these operations and track them down.
This is a good idea. Can you file a bug for this? I have thought of
doing this before but never thought anyone would appreciate things like
this. :)
> Now, if it was only easy to force all DCs and ADAM
> instances to have valid server certs, we'd be in business. :)
I think it goes w/o saying, but this is impossible. The definition of
"valid" is in the eye of the beholder. For example, to some a
self-signed cert, trusted by no one, is invalid for the DS. However, to
the person that explicitly trusted that cert on their LDAP clients, it's
perfectly fine. That's just one example, the same could be said for
nearly every wonky cert config you think of, especially when you
consider ADAM in the mix.
~Eric
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]SUBDOMAIN AND LDAP
That's very cool, Eric. I had no idea that setting existed in ADAM. Any
change of sneaking that into the AD stack?
I agree that it only solves half the problem, but at least by preventing
this from working at all, it keeps people from setting up apps that will do
unsecure simple binds thousands of times per day for years. There is only
so much you can do.
I also agree that SSL just isn't that easy and can't be, just because of the
way it works. That doesn't stop me from wishing it was. :) One thing I
like about ADFS is that you have to use SSL to play, so you can't even get
yourself in trouble.
I'll definitely file a bug on the audit thing. I think that would be nice,
even with ADAM in the mode to reject insecure simple binds, because you
could find out which clients are attempting it.
Joe K.
- Original Message -
From: "Eric Fleischman" <[EMAIL PROTECTED]>
To:
Sent: Sunday, September 24, 2006 11:48 AM
Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP
I'd love to see an AD and ADAM option that would allow the DS to
reject simple bind operations on non-SSL ports
We agree. That's why we built it in to the product. :) Well, in to ADAM
that is.
See object CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,CN={}. Check out the attribute
msds-other-settings, value named RequireSecureSimpleBind=0. Change that
0 to a 1, then you have enabled the protection.
I would point out, this does not prevent a client from *presenting* a
password via simple bind w/o connection security, only from the
operation succeeding. So you could still present a password (thereby
showing it to an attacker), it's just that it won't work. This is
training with the stick, not the carrot.
It's akin to saying, I can protect your SSN from working when you scream
it to me in a room full of people (ie, require you write it on a piece
of paper and pass it over), but I can't stop you from screaming, only
punish you when you make this bad choice.
Another thing that would be helpful would be an unencrypted simple
bind
audit event that could be configured, so that you could find the IP
address of any client issuing these operations and track them down.
This is a good idea. Can you file a bug for this? I have thought of
doing this before but never thought anyone would appreciate things like
this. :)
Now, if it was only easy to force all DCs and ADAM
instances to have valid server certs, we'd be in business. :)
I think it goes w/o saying, but this is impossible. The definition of
"valid" is in the eye of the beholder. For example, to some a
self-signed cert, trusted by no one, is invalid for the DS. However, to
the person that explicitly trusted that cert on their LDAP clients, it's
perfectly fine. That's just one example, the same could be said for
nearly every wonky cert config you think of, especially when you
consider ADAM in the mix.
~Eric
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]SUBDOMAIN AND LDAP
> I'd love to see an AD and ADAM option that would allow the DS to
> reject simple bind operations on non-SSL ports
We agree. That's why we built it in to the product. :) Well, in to ADAM
that is.
See object CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,CN={}. Check out the attribute
msds-other-settings, value named RequireSecureSimpleBind=0. Change that
0 to a 1, then you have enabled the protection.
I would point out, this does not prevent a client from *presenting* a
password via simple bind w/o connection security, only from the
operation succeeding. So you could still present a password (thereby
showing it to an attacker), it's just that it won't work. This is
training with the stick, not the carrot.
It's akin to saying, I can protect your SSN from working when you scream
it to me in a room full of people (ie, require you write it on a piece
of paper and pass it over), but I can't stop you from screaming, only
punish you when you make this bad choice.
> Another thing that would be helpful would be an unencrypted simple
bind
> audit event that could be configured, so that you could find the IP
> address of any client issuing these operations and track them down.
This is a good idea. Can you file a bug for this? I have thought of
doing this before but never thought anyone would appreciate things like
this. :)
> Now, if it was only easy to force all DCs and ADAM
> instances to have valid server certs, we'd be in business. :)
I think it goes w/o saying, but this is impossible. The definition of
"valid" is in the eye of the beholder. For example, to some a
self-signed cert, trusted by no one, is invalid for the DS. However, to
the person that explicitly trusted that cert on their LDAP clients, it's
perfectly fine. That's just one example, the same could be said for
nearly every wonky cert config you think of, especially when you
consider ADAM in the mix.
~Eric
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan
Sent: Sunday, September 24, 2006 9:16 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP
I think the bottom line of my argument boils down to "simple bind
without
SSL is evil, but simple bind with SSL is acceptable". Secure bind is
generally acceptable, with or without SSL.
As such, I'd love to see an AD and ADAM option that would allow the DS
to
reject simple bind operations on non-SSL ports. I think this would go a
long way towards helping enforce my mantra and would likely only have a
negative impact on non-MS apps using simple bind. The vast majority of
code
from the MS world uses secure bind by default and actually requires the
developer to go out of their way to get a simple bind. For example, the
basic vbscript:
Set obj = GetObject("LDAP://DC=domain,DC=com")
results in a secure bind with GSS-SPNEGO (hopefully negotiating to
Kerberos
:)). The same goes in .NET:
DirectoryEntry entry = new DirectoryEntry("LDAP://DC=domain,DC=com")
To get a simple bind, you must use OpenDSObject in script and pass in
the
appropriate flags to NOT have Secure bind set, or set the appropriate
AuthenticationTypes. In general, ADSI does the right thing.
Another thing that would be helpful would be an unencrypted simple bind
audit event that could be configured, so that you could find the IP
address
of any client issuing these operations and track them down.
I think one of the reasons why simple bind is used by many vendors is
that
it is the only common denominator between other directories and a lot of
LDAP protocol libraries don't support Microsoft auth mechanisms.
However,
the good news is that just about every LDAP library does have some sort
of
support for SSL. Now, if it was only easy to force all DCs and ADAM
instances to have valid server certs, we'd be in business. :)
Regarding the evolution of authentication protocols with some of the
stuff
in WS-*, I have to say that I like the vision. WS-Trust is the plumbing
under not only ADFS, but also CardSpace and the security framework for
Windows Communication Foundation (WCF). The vision is pretty appealing,
because the notion of how a user can be authenticated (via a security
token
service) is more abstract and based on open and fairly simple web
protocols
(HTTP, XML, PKI). The notion of a security token is now more abstract
and
flexible than a Windows token too, in that a token describing an
authenticated user now just contains "claims", not just SIDs. Claims
can be
anything (including their group SIDs), so this makes it easier to
provide
all the information an app needs to authorize a user without having to
resort to post authentication lookups to go back and get their first
name or
their email address. It also allows you to address privacy concerns, in
that each app can
Re: [ActiveDir]SUBDOMAIN AND LDAP
I think the bottom line of my argument boils down to "simple bind without
SSL is evil, but simple bind with SSL is acceptable". Secure bind is
generally acceptable, with or without SSL.
As such, I'd love to see an AD and ADAM option that would allow the DS to
reject simple bind operations on non-SSL ports. I think this would go a
long way towards helping enforce my mantra and would likely only have a
negative impact on non-MS apps using simple bind. The vast majority of code
from the MS world uses secure bind by default and actually requires the
developer to go out of their way to get a simple bind. For example, the
basic vbscript:
Set obj = GetObject("LDAP://DC=domain,DC=com")
results in a secure bind with GSS-SPNEGO (hopefully negotiating to Kerberos
:)). The same goes in .NET:
DirectoryEntry entry = new DirectoryEntry("LDAP://DC=domain,DC=com")
To get a simple bind, you must use OpenDSObject in script and pass in the
appropriate flags to NOT have Secure bind set, or set the appropriate
AuthenticationTypes. In general, ADSI does the right thing.
Another thing that would be helpful would be an unencrypted simple bind
audit event that could be configured, so that you could find the IP address
of any client issuing these operations and track them down.
I think one of the reasons why simple bind is used by many vendors is that
it is the only common denominator between other directories and a lot of
LDAP protocol libraries don't support Microsoft auth mechanisms. However,
the good news is that just about every LDAP library does have some sort of
support for SSL. Now, if it was only easy to force all DCs and ADAM
instances to have valid server certs, we'd be in business. :)
Regarding the evolution of authentication protocols with some of the stuff
in WS-*, I have to say that I like the vision. WS-Trust is the plumbing
under not only ADFS, but also CardSpace and the security framework for
Windows Communication Foundation (WCF). The vision is pretty appealing,
because the notion of how a user can be authenticated (via a security token
service) is more abstract and based on open and fairly simple web protocols
(HTTP, XML, PKI). The notion of a security token is now more abstract and
flexible than a Windows token too, in that a token describing an
authenticated user now just contains "claims", not just SIDs. Claims can be
anything (including their group SIDs), so this makes it easier to provide
all the information an app needs to authorize a user without having to
resort to post authentication lookups to go back and get their first name or
their email address. It also allows you to address privacy concerns, in
that each app can be configured to just get the info it needs and none that
it doesn't. Users can be given the right to control what information is
provided about them (which is very explicit in CardSpace, but is more of a
corporate policy thing with ADFS).
All in all, I'm digging the vision. I do think it has a long way to go
before it can become ubiquitous, but I do think it is a better model than
what we have now and the implementation is really simple and open enough
that everyone can play. Some would argue, probably rightly, that MS and IBM
have the keys to the kingdom and the stack is pretty complex with all the
layers of XML protocols. However, Kim Cameron has successfully demonstrated
CardSpace login to his blog running on the LAMP stack, so I'm convinced that
it is pretty doable.
When will we see the Security Token Service and WS-Trust displace the KDC
and SSPI in Windows? I think that will be a while. :)
And I love ADFS. It rocks. Bring on the Active Requester Profile (and a
better GUI)!
Joe K.
- Original Message -
From: "joe" <[EMAIL PROTECTED]>
To:
Sent: Sunday, September 24, 2006 10:10 AM
Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP
Yeah I understand, lots of vendors use LDAP for auth, but it doesn't make
it
good/right. Just like lots of vendors requiring admin access or always
passing NULL for LPSECURITY_ATTRIBUTES when working with securable
objects.
ADAM is another story, if you need to use ADAM principals you are stuck
with
using LDAP for the auth. I still don't like it though. :)
Of course you are correct on the using SSL can help beef up the security
but
that seems to be done in the minority of the cases. Far too many times
that
I have looked at LDAP traces I see passwords and IDs just flowing across
the
wire like there was no tomorrow. The thing is most of the users I expect
have no clue that they are being exposed in such a way because they trust
that the Administrators and vendors actually know what they are doing.
Course this is the case with many web based apps as well, but folks have
started to learn to mistrust these automatically as time goes by. The
little
"key" o
RE: [ActiveDir]SUBDOMAIN AND LDAP
Yeah I understand, lots of vendors use LDAP for auth, but it doesn't make it good/right. Just like lots of vendors requiring admin access or always passing NULL for LPSECURITY_ATTRIBUTES when working with securable objects. ADAM is another story, if you need to use ADAM principals you are stuck with using LDAP for the auth. I still don't like it though. :) Of course you are correct on the using SSL can help beef up the security but that seems to be done in the minority of the cases. Far too many times that I have looked at LDAP traces I see passwords and IDs just flowing across the wire like there was no tomorrow. The thing is most of the users I expect have no clue that they are being exposed in such a way because they trust that the Administrators and vendors actually know what they are doing. Course this is the case with many web based apps as well, but folks have started to learn to mistrust these automatically as time goes by. The little "key" on the browser helps a little but it tells you nothing about the backend and how insecure it is. I guess a possible configuration to help with this would be to configure IPSEC to only allow port 389/3268 to be used by replication partners. This would probably just break a ton of other stuff including anything using say kerberos/ntlm LDAP packet encryption or TSL as well as all of the non-secured stuff. As for the WS-* stuff, this is obviously more prevalent than just Web related techs. I admit to being completely uninformed on those protocols. Is your thought that those protocols are headed in the direction to be more universal and used even when Web access isn't even involved? joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan Sent: Saturday, September 23, 2006 12:15 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP Although a do tend to agree that LDAP does not define a good authentication protocol at all, it is definitely the case that LDAP is used as an authentication mechanism all over the place. I also don't thing there is really anything wrong with using it for that per say, as long as it is used correctly. Specifically, it is the LDAP bind operation that is typically used for authentication. The only real problem with using LDAP bind to authenticate a user is that the only binding mechanism defined directly by the LDAP V3 spec is the simple bind. Simple bind is not secure by itself because it passes the user's plaintext credentials over the wire. That is ultra bad, as any snooper can easily recover the user's password. However, when LDAP simple bind is combined with channel level encryption such as SSL, it really isn't that bad. :) Sure, I'd rather use Kerberos, but that isn't always an option. I've heard a few security experts suggest that you are actually safer using HTTP basic authentication with SSL over using NTLM auth over HTTP with no SSL. NTLM is actually that easy to hack. And NTLM actually IS an authentication protocol (albeit a dated, deprecated protocol that we still can't seem to get rid of in Windows over 6 years after it fell out of favor over Kerberos). When using ADAM as an identity store, the primary means you have available to you to authenticate your ADAM users is LDAP simple bind (although digest auth is available if the client knows how to speak it; most don't). If you want to use the fast concurrent bind feature of ADAM or AD, simple bind is the only supported authentication mechanism. The real key is to ensure that simple bind is always combined with SSL (or some other transport layer security like IPSEC). I'd actually love to see an option in AD and ADAM that would only allow simple bind on a secure channel. I think that would be a good product feature, although it would probably have to be off by default. I don't expect to see lots of third party apps moving away from LDAP bind as an authentication mechanism until something else more universal rises up to replace it. I'm hoping that's WS-Federation/WS-Trust, but somehow I doubt we'll see that very soon. :) Joe K. - Original Message - From: "joe" <[EMAIL PROTECTED]> To: Sent: Friday, September 22, 2006 8:07 PM Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP > The first thing I would say and I am shocked Al didn't say is > > > LDAP IS NOT AN AUTHENTICATION PROTOCOL > > For the the managers and vendors let me repeat ;o) > > LDAP > IS > NOT > AN > AUTHENTICATION > PROTOCOL > > > > LDAP has to authenticate as a part of giving secure access to data but > that > doesn't make it an authentication protocol. A file server has to > authenticate you in some way
RE: [ActiveDir]SUBDOMAIN AND LDAP
"I agree that a vendor should have a minimum qualification to meet to be able
to call it AD Integrated. "
Aye, something like the wildly successful XP Logo program that ensures all the
apps we use are written well and don't need administrative rights to run.
From: [EMAIL PROTECTED] on behalf of Al Mulnick
Sent: Sat 9/23/2006 7:31 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP
Sorry Sir!
(I see you hit the other reasons quite well. The DN is such a PITA to begin
with if you're trying to use LDAP to authenticate and authorize a user).
That's often the biggest complaint I have when somebody tries to integrate with
AD via LDAP. That and you end up having to dumb it down so the app will talk to
AD.
I agree that a vendor should have a minimum qualification to meet to be able to
call it AD Integrated. Otherwise, it's just ldap and they should call it that.
I'll try to be quicker on the draw sir! :)
On 9/22/06, joe <[EMAIL PROTECTED]> wrote:
LOL. You should have sent this before I started typing. ;o)
Why wasn't it in your first answer, you always take that one right out
in the first paragraph and when I read your response I was like hey who the
heck are you?
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al
Mulnick
Sent: Friday, September 22, 2006 8:55 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP
I won't put words in his mouth either, but I'll certainly say the same
thing. I had to hold back a shudder when I responded earlier 'cause ldap and
authentication might be ok in the same paragraph, but never in the same
sentence (except to point out that it should not be in the same sentence :)
Would it work if you used the parent domain in a contiguous namespace
design? Depends on how they wrote the code. If it won't follow referrals then
likely it will fail.
Try the GC (that is so lame a workaround, but it'll likely work) as Joe
suggests and at the same push back on the vendor to get it right or give you
your money back else give you a more solid workaround (ADAM?)
There. Nothing for joe to tell them about fixing their lame app.
-ajm
On 9/22/06, Joe Kaplan <[EMAIL PROTECTED]> wrote:
You might have them try to work with the GC. You should be
able to
authenticate and find users from any domain via the GC.
I think Joe Richards might also suggest that the vendor learn
what they are
doing and either integrate with AD the right way or don't claim
they can.
I'll bet they need to talk to a specific domain controller too.
I won't put
words in Joe's mouth though. :)
Joe
- Original Message -
From: Ramon Linan
To: ActiveDir@mail.activedir.org
Sent: Friday, September 22, 2006 3:41 PM
Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP
The application designer is telling me it can only be
configured for one
source of authentication, so if the use the domain level
authentication will
that allow to authenticate users in the subdomain?
I.e.
domain.com <http://domain.com/>
child.domain.com <http://child.domain.com/>
If I point the application to use domain.com
<http://domain.com/> as authentication source will
that also authenticate users from the child domain?
Thanks
From: [EMAIL PROTECTED]
[mailto: [EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Friday, September 22, 2006 4:19 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP
sub-domain query base: dc=subdomain,dc=domain,dc=com
domain query base: dc=domain,dc=com
When the search is initiated, it will start looking at the
query base and,
if so configured, everything below it (subtree search).
In your case, that won't likely happen depen
Re: [ActiveDir]SUBDOMAIN AND LDAP
Sorry Sir! (I see you hit the other reasons quite well. The DN is such a PITA to begin with if you're trying to use LDAP to authenticate and authorize a user). That's often the biggest complaint I have when somebody tries to integrate with AD via LDAP. That and you end up having to dumb it down so the app will talk to AD. I agree that a vendor should have a minimum qualification to meet to be able to call it AD Integrated. Otherwise, it's just ldap and they should call it that. I'll try to be quicker on the draw sir! :)On 9/22/06, joe <[EMAIL PROTECTED]> wrote: LOL. You should have sent this before I started typing. ;o) Why wasn't it in your first answer, you always take that one right out in the first paragraph and when I read your response I was like hey who the heck are you? -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Friday, September 22, 2006 8:55 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir]SUBDOMAIN AND LDAP I won't put words in his mouth either, but I'll certainly say the same thing. I had to hold back a shudder when I responded earlier 'cause ldap and authentication might be ok in the same paragraph, but never in the same sentence (except to point out that it should not be in the same sentence :) Would it work if you used the parent domain in a contiguous namespace design? Depends on how they wrote the code. If it won't follow referrals then likely it will fail. Try the GC (that is so lame a workaround, but it'll likely work) as Joe suggests and at the same push back on the vendor to get it right or give you your money back else give you a more solid workaround (ADAM?) There. Nothing for joe to tell them about fixing their lame app. -ajm On 9/22/06, Joe Kaplan <[EMAIL PROTECTED]> wrote: You might have them try to work with the GC. You should be able toauthenticate and find users from any domain via the GC. I think Joe Richards might also suggest that the vendor learn what they aredoing and either integrate with AD the right way or don't claim they can.I'll bet they need to talk to a specific domain controller too. I won't put words in Joe's mouth though. :)Joe- Original Message -From: Ramon LinanTo: ActiveDir@mail.activedir.orgSent: Friday, September 22, 2006 3:41 PM Subject: RE: [ActiveDir]SUBDOMAIN AND LDAPThe application designer is telling me it can only be configured for onesource of authentication, so if the use the domain level authentication willthat allow to authenticate users in the subdomain? I.e.domain.com child.domain.comIf I point the application to use domain.com as authentication source will that also authenticate users from the child domain?ThanksFrom: [EMAIL PROTECTED][mailto: [EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Friday, September 22, 2006 4:19 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir]SUBDOMAIN AND LDAP sub-domain query base: dc=subdomain,dc=domain,dc=comdomain query base: dc=domain,dc=comWhen the search is initiated, it will start looking at the query base and,if so configured, everything below it (subtree search). In your case, that won't likely happen depending on how you configured it.If you instead change your query base to dc=domain,dc=com (assuming you havea contiguous namespace) then you may get different results. Testing. You can use ldp, adfind, or any other ldap client if your appdoesn't have that functionality built in.Since you're security conscious, be mindful of the cert and the ports you'reusing during your testing :) Permissions? That depends on your configuration and your versions. Windows2000 is pretty much open for searches while 2003 requires authenticatedusers by default.AlOn 9/22/06, Ramon Linan < [EMAIL PROTECTED]> wrote:Hi,I have an application that uses LDAP to authenticate (authenticatesagainst AD).In my AD I have a domain and subdomain or child domain. I assume that both domain and subdomain uses the same LDAP, right?Also, if the application is using a user from the subdomain to query theLDAP, what kind of access will that user have to have to authenticate users at the main domain level.Basically, the application is authenticating fine the users from thesubdomain but cant fine the users from the main domain...Thanks for any advice.Rezuma List info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspxList info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
Re: [ActiveDir]SUBDOMAIN AND LDAP
Although a do tend to agree that LDAP does not define a good authentication protocol at all, it is definitely the case that LDAP is used as an authentication mechanism all over the place. I also don't thing there is really anything wrong with using it for that per say, as long as it is used correctly. Specifically, it is the LDAP bind operation that is typically used for authentication. The only real problem with using LDAP bind to authenticate a user is that the only binding mechanism defined directly by the LDAP V3 spec is the simple bind. Simple bind is not secure by itself because it passes the user's plaintext credentials over the wire. That is ultra bad, as any snooper can easily recover the user's password. However, when LDAP simple bind is combined with channel level encryption such as SSL, it really isn't that bad. :) Sure, I'd rather use Kerberos, but that isn't always an option. I've heard a few security experts suggest that you are actually safer using HTTP basic authentication with SSL over using NTLM auth over HTTP with no SSL. NTLM is actually that easy to hack. And NTLM actually IS an authentication protocol (albeit a dated, deprecated protocol that we still can't seem to get rid of in Windows over 6 years after it fell out of favor over Kerberos). When using ADAM as an identity store, the primary means you have available to you to authenticate your ADAM users is LDAP simple bind (although digest auth is available if the client knows how to speak it; most don't). If you want to use the fast concurrent bind feature of ADAM or AD, simple bind is the only supported authentication mechanism. The real key is to ensure that simple bind is always combined with SSL (or some other transport layer security like IPSEC). I'd actually love to see an option in AD and ADAM that would only allow simple bind on a secure channel. I think that would be a good product feature, although it would probably have to be off by default. I don't expect to see lots of third party apps moving away from LDAP bind as an authentication mechanism until something else more universal rises up to replace it. I'm hoping that's WS-Federation/WS-Trust, but somehow I doubt we'll see that very soon. :) Joe K. - Original Message - From: "joe" <[EMAIL PROTECTED]> To: Sent: Friday, September 22, 2006 8:07 PM Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP The first thing I would say and I am shocked Al didn't say is LDAP IS NOT AN AUTHENTICATION PROTOCOL For the the managers and vendors let me repeat ;o) LDAP IS NOT AN AUTHENTICATION PROTOCOL LDAP has to authenticate as a part of giving secure access to data but that doesn't make it an authentication protocol. A file server has to authenticate you in some way shape or form for you to safely access files too; I don't see people stumbling over themselves to use that as an authentication protocol. The only reason this comes in from the *NIX world like this is because Kerberos can be a serious pain in the ass there. Tough, use a real authentication protocol. If the vendor is using it to authenticate and that is all they are doing my comment to them is get off your ass and use a real auth protocol and with Windows the proper auth protocol is Kerberos. Most Windows folks don't even have a clue to the technical depth and complexity of Kerberos because Microsoft did such a bang up job of burying the details for most things Windows. So if someone doesn't use it, that is their issue, not Microsoft's. Following up of course with the things JoeK said which I fully concur with. If using LDAP to authenticate though, where in the tree you poke doesn't matter, as long as the user is a member of that forest, if you specify their ID and their password, it will authenticate them by passing the traffic to whatever DC is required. However, the app should be smart enough to ask the proper DC out of the box. And when you specify the ID, specify either UPN or Domain\UserID, do not use DN. Why? Because DN's change and if you allow the apps to say, you have to stick with a certain DN then you have lost a bunch of flexibility of AD. Finally, if they don't do basic things like this right, I wonder what your chances are that they do harder things like attribute ranging and paging right. AD is an extremely robust directory service and have tons of failover and location services built into it. It has been out for 6 years in production now, much longer in beta phases, etc and if apps still don't know what they are doing with it I would greatly question the programmers and the vendor. It is outright stupid to make your robust directory lower itself to the standards of a poorly written app. If the app requires and of the following: 1. Fixed DNs 2. All users under a single bas
RE: [ActiveDir]SUBDOMAIN AND LDAP
LOL. You should have sent this before I started typing. ;o) Why wasn't it in your first answer, you always take that one right out in the first paragraph and when I read your response I was like hey who the heck are you? -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Friday, September 22, 2006 8:55 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir]SUBDOMAIN AND LDAP I won't put words in his mouth either, but I'll certainly say the same thing. I had to hold back a shudder when I responded earlier 'cause ldap and authentication might be ok in the same paragraph, but never in the same sentence (except to point out that it should not be in the same sentence :) Would it work if you used the parent domain in a contiguous namespace design? Depends on how they wrote the code. If it won't follow referrals then likely it will fail. Try the GC (that is so lame a workaround, but it'll likely work) as Joe suggests and at the same push back on the vendor to get it right or give you your money back else give you a more solid workaround (ADAM?) There. Nothing for joe to tell them about fixing their lame app. -ajm On 9/22/06, Joe Kaplan <[EMAIL PROTECTED]> wrote: You might have them try to work with the GC. You should be able toauthenticate and find users from any domain via the GC. I think Joe Richards might also suggest that the vendor learn what they aredoing and either integrate with AD the right way or don't claim they can.I'll bet they need to talk to a specific domain controller too. I won't put words in Joe's mouth though. :)Joe- Original Message -From: Ramon LinanTo: ActiveDir@mail.activedir.orgSent: Friday, September 22, 2006 3:41 PM Subject: RE: [ActiveDir]SUBDOMAIN AND LDAPThe application designer is telling me it can only be configured for onesource of authentication, so if the use the domain level authentication willthat allow to authenticate users in the subdomain? I.e.domain.comchild.domain.comIf I point the application to use domain.com as authentication source will that also authenticate users from the child domain?ThanksFrom: [EMAIL PROTECTED][mailto: [EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Friday, September 22, 2006 4:19 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir]SUBDOMAIN AND LDAP sub-domain query base: dc=subdomain,dc=domain,dc=comdomain query base: dc=domain,dc=comWhen the search is initiated, it will start looking at the query base and,if so configured, everything below it (subtree search). In your case, that won't likely happen depending on how you configured it.If you instead change your query base to dc=domain,dc=com (assuming you havea contiguous namespace) then you may get different results. Testing. You can use ldp, adfind, or any other ldap client if your appdoesn't have that functionality built in.Since you're security conscious, be mindful of the cert and the ports you'reusing during your testing :) Permissions? That depends on your configuration and your versions. Windows2000 is pretty much open for searches while 2003 requires authenticatedusers by default.AlOn 9/22/06, Ramon Linan < [EMAIL PROTECTED]> wrote:Hi,I have an application that uses LDAP to authenticate (authenticatesagainst AD).In my AD I have a domain and subdomain or child domain. I assume that both domain and subdomain uses the same LDAP, right?Also, if the application is using a user from the subdomain to query theLDAP, what kind of access will that user have to have to authenticate users at the main domain level.Basically, the application is authenticating fine the users from thesubdomain but cant fine the users from the main domain...Thanks for any advice.Rezuma List info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspxList info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir]SUBDOMAIN AND LDAP
The first thing I would say and I am shocked Al didn't say is LDAP IS NOT AN AUTHENTICATION PROTOCOL For the the managers and vendors let me repeat ;o) LDAP IS NOT AN AUTHENTICATION PROTOCOL LDAP has to authenticate as a part of giving secure access to data but that doesn't make it an authentication protocol. A file server has to authenticate you in some way shape or form for you to safely access files too; I don't see people stumbling over themselves to use that as an authentication protocol. The only reason this comes in from the *NIX world like this is because Kerberos can be a serious pain in the ass there. Tough, use a real authentication protocol. If the vendor is using it to authenticate and that is all they are doing my comment to them is get off your ass and use a real auth protocol and with Windows the proper auth protocol is Kerberos. Most Windows folks don't even have a clue to the technical depth and complexity of Kerberos because Microsoft did such a bang up job of burying the details for most things Windows. So if someone doesn't use it, that is their issue, not Microsoft's. Following up of course with the things JoeK said which I fully concur with. If using LDAP to authenticate though, where in the tree you poke doesn't matter, as long as the user is a member of that forest, if you specify their ID and their password, it will authenticate them by passing the traffic to whatever DC is required. However, the app should be smart enough to ask the proper DC out of the box. And when you specify the ID, specify either UPN or Domain\UserID, do not use DN. Why? Because DN's change and if you allow the apps to say, you have to stick with a certain DN then you have lost a bunch of flexibility of AD. Finally, if they don't do basic things like this right, I wonder what your chances are that they do harder things like attribute ranging and paging right. AD is an extremely robust directory service and have tons of failover and location services built into it. It has been out for 6 years in production now, much longer in beta phases, etc and if apps still don't know what they are doing with it I would greatly question the programmers and the vendor. It is outright stupid to make your robust directory lower itself to the standards of a poorly written app. If the app requires and of the following: 1. Fixed DNs 2. All users under a single base 3. someone to change the ranging values 4. someone to change the paging values 5. a fixed hostname 6. Non-nested groups 7. etc etc etc Then really investigate that app because it is a pain in the ass. The only time you should be talking fixed hostnames versus auto service location is in the case of syncronization. That is the one case where it is a bit difficult to bounce between DCs but I have seen apps that can pull this off, though they are less efficient because they have to regather their bearings every time they jump DCs. Most applications do not have this issue. Especially apps doing basic auth/authz/data lookup. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan Sent: Friday, September 22, 2006 5:41 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP You might have them try to work with the GC. You should be able to authenticate and find users from any domain via the GC. I think Joe Richards might also suggest that the vendor learn what they are doing and either integrate with AD the right way or don't claim they can. I'll bet they need to talk to a specific domain controller too. I won't put words in Joe's mouth though. :) Joe - Original Message - From: Ramon Linan To: ActiveDir@mail.activedir.org Sent: Friday, September 22, 2006 3:41 PM Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP The application designer is telling me it can only be configured for one source of authentication, so if the use the domain level authentication will that allow to authenticate users in the subdomain? I.e. domain.com child.domain.com If I point the application to use domain.com as authentication source will that also authenticate users from the child domain? Thanks From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Friday, September 22, 2006 4:19 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP sub-domain query base: dc=subdomain,dc=domain,dc=com domain query base: dc=domain,dc=com When the search is initiated, it will start looking at the query base and, if so configured, everything below it (subtree search). In your case, that won't likely happen depending on how you configured it. If you instead change your query base to dc=domain,dc=com (assuming you have a contiguous namespace) then you may get di
Re: [ActiveDir]SUBDOMAIN AND LDAP
I won't put words in his mouth either, but I'll certainly say the same thing. I had to hold back a shudder when I responded earlier 'cause ldap and authentication might be ok in the same paragraph, but never in the same sentence (except to point out that it should not be in the same sentence :) Would it work if you used the parent domain in a contiguous namespace design? Depends on how they wrote the code. If it won't follow referrals then likely it will fail. Try the GC (that is so lame a workaround, but it'll likely work) as Joe suggests and at the same push back on the vendor to get it right or give you your money back else give you a more solid workaround (ADAM?) There. Nothing for joe to tell them about fixing their lame app. -ajm On 9/22/06, Joe Kaplan <[EMAIL PROTECTED]> wrote: You might have them try to work with the GC. You should be able toauthenticate and find users from any domain via the GC. I think Joe Richards might also suggest that the vendor learn what they aredoing and either integrate with AD the right way or don't claim they can.I'll bet they need to talk to a specific domain controller too. I won't put words in Joe's mouth though. :)Joe- Original Message -From: Ramon LinanTo: ActiveDir@mail.activedir.orgSent: Friday, September 22, 2006 3:41 PM Subject: RE: [ActiveDir]SUBDOMAIN AND LDAPThe application designer is telling me it can only be configured for onesource of authentication, so if the use the domain level authentication willthat allow to authenticate users in the subdomain? I.e.domain.comchild.domain.comIf I point the application to use domain.com as authentication source will that also authenticate users from the child domain?ThanksFrom: [EMAIL PROTECTED][mailto: [EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Friday, September 22, 2006 4:19 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir]SUBDOMAIN AND LDAP sub-domain query base: dc=subdomain,dc=domain,dc=comdomain query base: dc=domain,dc=comWhen the search is initiated, it will start looking at the query base and,if so configured, everything below it (subtree search). In your case, that won't likely happen depending on how you configured it.If you instead change your query base to dc=domain,dc=com (assuming you havea contiguous namespace) then you may get different results. Testing. You can use ldp, adfind, or any other ldap client if your appdoesn't have that functionality built in.Since you're security conscious, be mindful of the cert and the ports you'reusing during your testing :) Permissions? That depends on your configuration and your versions. Windows2000 is pretty much open for searches while 2003 requires authenticatedusers by default.AlOn 9/22/06, Ramon Linan < [EMAIL PROTECTED]> wrote:Hi,I have an application that uses LDAP to authenticate (authenticatesagainst AD).In my AD I have a domain and subdomain or child domain. I assume that both domain and subdomain uses the same LDAP, right?Also, if the application is using a user from the subdomain to query theLDAP, what kind of access will that user have to have to authenticate users at the main domain level.Basically, the application is authenticating fine the users from thesubdomain but cant fine the users from the main domain...Thanks for any advice.Rezuma List info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspxList info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
Re: [ActiveDir]SUBDOMAIN AND LDAP
You might have them try to work with the GC. You should be able to authenticate and find users from any domain via the GC. I think Joe Richards might also suggest that the vendor learn what they are doing and either integrate with AD the right way or don't claim they can. I'll bet they need to talk to a specific domain controller too. I won't put words in Joe's mouth though. :) Joe - Original Message - From: Ramon Linan To: ActiveDir@mail.activedir.org Sent: Friday, September 22, 2006 3:41 PM Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP The application designer is telling me it can only be configured for one source of authentication, so if the use the domain level authentication will that allow to authenticate users in the subdomain? I.e. domain.com child.domain.com If I point the application to use domain.com as authentication source will that also authenticate users from the child domain? Thanks From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Friday, September 22, 2006 4:19 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP sub-domain query base: dc=subdomain,dc=domain,dc=com domain query base: dc=domain,dc=com When the search is initiated, it will start looking at the query base and, if so configured, everything below it (subtree search). In your case, that won't likely happen depending on how you configured it. If you instead change your query base to dc=domain,dc=com (assuming you have a contiguous namespace) then you may get different results. Testing. You can use ldp, adfind, or any other ldap client if your app doesn't have that functionality built in. Since you're security conscious, be mindful of the cert and the ports you're using during your testing :) Permissions? That depends on your configuration and your versions. Windows 2000 is pretty much open for searches while 2003 requires authenticated users by default. Al On 9/22/06, Ramon Linan <[EMAIL PROTECTED]> wrote: Hi, I have an application that uses LDAP to authenticate (authenticates against AD). In my AD I have a domain and subdomain or child domain. I assume that both domain and subdomain uses the same LDAP, right? Also, if the application is using a user from the subdomain to query the LDAP, what kind of access will that user have to have to authenticate users at the main domain level. Basically, the application is authenticating fine the users from the subdomain but cant fine the users from the main domain... Thanks for any advice. Rezuma 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]SUBDOMAIN AND LDAP
The application designer is telling me it can only be configured for one source of authentication, so if the use the domain level authentication will that allow to authenticate users in the subdomain? I.e. domain.com child.domain.com If I point the application to use domain.com as authentication source will that also authenticate users from the child domain? Thanks From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Friday, September 22, 2006 4:19 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir]SUBDOMAIN AND LDAP sub-domain query base: dc=subdomain,dc=domain,dc=comdomain query base: dc=domain,dc=comWhen the search is initiated, it will start looking at the query base and, if so configured, everything below it (subtree search). In your case, that won't likely happen depending on how you configured it. If you instead change your query base to dc=domain,dc=com (assuming you have a contiguous namespace) then you may get different results. Testing. You can use ldp, adfind, or any other ldap client if your app doesn't have that functionality built in. Since you're security conscious, be mindful of the cert and the ports you're using during your testing :) Permissions? That depends on your configuration and your versions. Windows 2000 is pretty much open for searches while 2003 requires authenticated users by default. Al On 9/22/06, Ramon Linan <[EMAIL PROTECTED]> wrote: Hi,I have an application that uses LDAP to authenticate (authenticatesagainst AD).In my AD I have a domain and subdomain or child domain.I assume that both domain and subdomain uses the same LDAP, right? Also, if the application is using a user from the subdomain to query theLDAP, what kind of access will that user have to have to authenticateusers at the main domain level.Basically, the application is authenticating fine the users from the subdomain but cant fine the users from the main domain...Thanks for any advice.RezumaList info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
Re: [ActiveDir]SUBDOMAIN AND LDAP
sub-domain query base: dc=subdomain,dc=domain,dc=comdomain query base: dc=domain,dc=comWhen the search is initiated, it will start looking at the query base and, if so configured, everything below it (subtree search). In your case, that won't likely happen depending on how you configured it. If you instead change your query base to dc=domain,dc=com (assuming you have a contiguous namespace) then you may get different results. Testing. You can use ldp, adfind, or any other ldap client if your app doesn't have that functionality built in. Since you're security conscious, be mindful of the cert and the ports you're using during your testing :) Permissions? That depends on your configuration and your versions. Windows 2000 is pretty much open for searches while 2003 requires authenticated users by default. Al On 9/22/06, Ramon Linan <[EMAIL PROTECTED]> wrote: Hi,I have an application that uses LDAP to authenticate (authenticatesagainst AD).In my AD I have a domain and subdomain or child domain.I assume that both domain and subdomain uses the same LDAP, right? Also, if the application is using a user from the subdomain to query theLDAP, what kind of access will that user have to have to authenticateusers at the main domain level.Basically, the application is authenticating fine the users from the subdomain but cant fine the users from the main domain...Thanks for any advice.RezumaList info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
