RE: [ActiveDir] Urgent DFS Configuration
Steve, Happy to pick up the hijack... Bad news - upgrading to R2 introduces DFSR and the "new" DFS as a whole new ball game. Old and existing DFS/FRS roots will continue as they are. If you wish them to use the new system, the old one should be deleted and created using the new DFS console. As for a guide... nothing that I have found, but that doesn't mean one doesn't exist (I usually do not look to hard for things like that, but that is just me). I do not believe there is a "magic" conversion from one to the other... yet... The new DFS is much more intuitive than the original, so it should be pretty straight forward. Thanks! :) themolk. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve RochfordSent: Friday, 22 September 2006 10:43 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Urgent DFS Configuration Slighlty hijacking the thread, if I have a 2003 DFS with replication running and would like to make it 2003 R2 DFSR can I: Upgrade to 2003 R2 Magically convert from DFS to DFSR If so, is there a guide anywhere to what to do? Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Molkentin, SteveSent: 22 September 2006 00:52To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Urgent DFS Configuration Additionally.. there are many catches with DFS when you start replicating files (if you were intending to). As a (R1 speak) root link, it is pretty simple, however you have to ensure you have your NTFS and share permissions set correctly before you create the DFS root and additional links or folders, etc, etc, etc. If you are planning to replicate files, then MAKE SURE you are running R2 otherwise you'll have all sorts of file replication traumas using FRS... I love DFSR! themolk. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott, AnthonySent: Friday, 22 September 2006 6:32 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Urgent DFS Configuration Are you trying to access the folders that DFS created or the actual shares themselves? See this (it applies to 2003 also): http://support.microsoft.com/default.aspx?scid=kb;en-us;q246888 Thanks, Anthony Scott Microsoft Consultant Mobile 616-481-9722 | Desk 616-464-6369 | [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ibarra, JuanSent: Thursday, September 21, 2006 2:42 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Urgent DFS Configuration That would be 2. Juan From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: Thursday, September 21, 2006 10:11 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Urgent DFS Configuration which server hosts the stand alone root? server 1 or 2? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ibarra, JuanSent: Thursday, September 21, 2006 17:34To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Urgent DFS ConfigurationImportance: High All, I need some input on DFS. I am trying to set up DFS on a file server, well in reality two. I am configuring server1 with a standalone root, when asked for the host server I enter server2 and select the share drive I want to use. I then create DFS links to subfolders and they create just fine. The problem: When I try to access the links I created I cant Access Denied even though I share the folders in advance with appropriate permissions, and of course at this point the security tab from the shares disappears. So I cant make changes, and when I go and try to open from DFS I get an error Failed to launch explorer home at \\pathname. I also rebooted both servers and when they come up the DFS root is gone from server1 but remains on server 2 along with all the DFS links. Please let me know what I am doing wrong. Thanks, Juan This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
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: ActiveDir@mail.activedir.org 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
RE: [ActiveDir] SID History.
I would recommend poking through the MSDN security docs. It sounds like thereis a break in understanding of how the SIDs are used in combination with the DACLS. Start here: http://msdn.microsoft.com/library/default.asp?url=""> but poke around that whole area. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt HargravesSent: Thursday, September 21, 2006 4:59 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] SID History. Conceptual situation:User domainResource domain (s)I bring all users into a single AD environment, bringing over SID History information.Now I start moving over file servers from the resource domain to the AD environment. One of the file servers has groups ACL'd from the resource domain. When the server goes to check for access rights, will it pull over *all* group memberships from the appropriate resource domain or simply pull over the single group membership and append that to the user's token? Mostly just looking at SID history impact between semi-active resource domains that are being decomissioned and current domains. Microsoft's site mostly seems to point to groups that are pointing to SID history objects that are within the AD environment, not cross-domain SID history impact.
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: ActiveDir@mail.activedir.org 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 on the browser helps a little but it tells you nothing about the backend and how insecure it
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={GUID}. 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 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
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: ActiveDir@mail.activedir.org
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={GUID}. 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] Assign User rights overs computers with AD
Right. However, when you say different trees, the expecation is that you have created a separate domain and/or forest for them. If you had said something along the lines of a separate OU so that you could manage them,I think we'd get the idea. From the sounds of it, we still don't quite know what you were suggesting but my guess is that you mean to move them to a new OU that makes the grouping make more sense for your administrative model. Al On 9/23/06, Dave Wade [EMAIL PROTECTED] wrote: I usually move them out as you can't apply GPO at the computers level... From: [EMAIL PROTECTED] on behalf of Alberto OviedoSent: Fri 22/09/2006 22:40To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Assign User rights overs computers with ADHey Dave. Do you mean separate trees under root computers? or Create different OU's for computers?On 9/22/06, Al Mulnick [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Separate Trees? That seems a little excessive.Or are we just mixing terms? On 9/21/06, Dave Wade [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I prefer to keep them in seperate trees. In fact we are just doing that at present... From: [EMAIL PROTECTED] on behalf of Alberto Oviedo Sent: Thu 21/09/2006 17:50 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Assign User rights overs computers with AD Thanks for your help. really useful. Is it a good practice to move computer objects to OU where the user of the computer resides? On 9/20/06, Dave Wade [EMAIL PROTECTED] wrote: Alberto,Even though we made our users PowerUsers we found that we needed to make a number of tweaks to cater for poorly written applications. I think we now have about a dozen settings for various ill-behaved applications. The majority of these are to cater for applications that write to places on the C drive (other than the windows folders, of course) where applications should not write. We also refreshed permissions on the all users profile to make sure users don't delete items from the all users desktop or start-menu. I guess the last thing to note is that we rolled the policy out in manageable chunks of PCs, say 100 at a time, so if there were issues we could cope with the service calls, Hope this is useful, Dave. From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Al Mulnick Sent: 20 September 2006 14:13 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Assign User rights overs computers with AD You can, but I've yet to see it be so simple.The information you're looking for is restricted groups but I HIGHLY advise you to be careful and to TEST that prior to using it on your workstations.I also highly advise that you only apply that type of setting to workstations and not on servers (separate them into different OU's). Another way to do this is with a logon script that adds an account to the local administrators group and removes the user from that group. The testing is a way to ensure that you don't break applications on the workstations.Some of the more poorly written applications require special access and as a default prefer administrative access rights. They work poorly without them.You'll want to test thoroughly so that you can remove the unneeded rights and still allow your user community to work as expected. I'm sure there's more cautions I can suggest, but you get the idea. On 9/20/06, Alberto Oviedo [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello. My name is Alberto, I'm from Nicaragua In our company the support team has granted every user administrator rights over their workstation, We recently migrated to Windows 2003 AD and I want to revoke the privileges tha users have on their computers. Can I do this through AD? It's around 300 users and I don't want to visit every single one of them. Thanks for your help. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. As a public body, the Council may be required to disclose this email, or any response to it, under the Freedom of Information Act 2000, unless the information in it is covered by one of the exemptions in the Act. If you receive this email in error please notify Stockport e-Services via [EMAIL PROTECTED] and then permanently remove it from your system. Thank you. http://www.stockport.gov.uk **
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: ActiveDir@mail.activedir.org
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={GUID}. 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
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] ADFS and certs (was: SUBDOMAIN AND LDAP)
I agree that there is a certain amount of pain with certs and ADFS, although I don't think it is really that hard, especially if you go the commercial route. The thing I like about it is that since it requires you to get this working to use it, it is secure by default. You have little ability to hoist yourself by your own petards, so to speak. :) There are really two parts to the ADFS cert story, the SSL/HTTP part and the token signing cert part. The SSL/HTTP part is a little more straightforward and is the kind of thing that lots of organizations do successfully already on their public websites now. You really only tend to get yourself in trouble if you want to self issue certs and do things like issue from your own root or publish your CRL in a non-public place. The token signing cert part of ADFS is much more black magic and needs more guidance. Even with certs that work perfectly fine for SSL, we had trouble using them for token signing due to the additional CRL checking that ADFS does and had to disable that in policy. I think similar things happened to you guys with one of your partner's token signing certs in your own internal implementation. CRL is an important idea whose implementation is basically broken in the general case, as there is no reasonable way to always get the CRL programmatically. Windows could do a lot better with tool support for troubleshooting this and better error messages though (kind of like Kerberos delegation; too hard as it stands!). I'm sure my experiences are influenced by the fact that I already know a fair amount about certs and SSL, having spent a full year of my life implementing an automated certificate provisioning system for end user signing and encryption certs that ties into our overall identity management process. I can totally see how there is a bunch of mumbo jumbo to overcome for those not really familiar with PKI. At least in this case, though, the mumbo jumbo (PKI) is pretty much the same on Linux or Sun as it is on Windows. It doesn't really hurt the adoption of protocol itself across platforms. I also think the ADFS step by step guide leads people down a dark path, in that all the demos are set up with selfssl and self-issued certs, which are ok for demos, but not cool for production (IMO). The path to get from the demo set up in step by step to your actual scenario is not always easy to do. I think our internal proof of concept was more successful because we tried to build our POC the way we thought we'd actually use the product internally, rather than using the Adatum/Trey Research scenarios. As with most new things that take some thought to implement, the skills and experiences needed to crank out good implemenations quickly will lag the product for a while. I'm sure the first year or two (or maybe more!) of AD installs were slow and a little crappy too. I still like the product though. :) I think the places where it is sound, it is very sound. It has a good base to build on. Joe K. - Original Message - From: Eric Fleischman [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Sunday, September 24, 2006 1:25 PM Subject: 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: ActiveDir@mail.activedir.org Sent: Sunday,
Re: [ActiveDir] ADFS and certs
Joe Kaplan wrote: (...) I also think the ADFS step by step guide leads people down a dark path, in that all the demos are set up with selfssl and self-issued certs, which are ok for demos, but not cool for production (IMO) (...) Will jump with few word from myself again - I can agree on Your point regarding step by step in 100%. When I've tried to setup my first ADFS lab I've decided to use Windows 2003 CA instead of Self issued certs and for me it was far more natural way to use ADFS than this not-realistic SelfSSL scenario, which may be confusing for users. I've exchanged e-mail with peoples on internal mailing list few times about it and one good information is that this point was taken and updated version of step by step document for ADFS should be better on this. -- 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] I'm Baaaaaaack!
Good idea! BTW, good job on the Cookbook with Robbie. Top-notch, Laura. Rick From: Laura E. Hunter [EMAIL PROTECTED] Reply-To: ActiveDir@mail.activedir.org To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] I'm Baaack! Date: Thu, 21 Sep 2006 16:25:10 -0400 Quick! Hide the good silverware! On 9/21/06, Akomolafe, Deji [EMAIL PROTECTED] wrote: Yikes! Is it Halloween yet? Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) /|_/(__(_) // (_(_)(/_(_(_/(__(/_ (_/ /) (/ Microsoft MVP - Directory Services www.akomolafe.com - we know IT -5.75, -3.23 Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: Rick Kingslan Sent: Thu 9/21/2006 11:00 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] I'm Baaack! Be afraid Be very afraid! :-) Rick _ Be seen and heard with Windows Live Messenger and Microsoft LifeCams http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http://www.microsoft.com/hardware/digitalcommunication/default.mspx?locale=en-ussource=hmtagline 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 -- --- Laura E. Hunter Microsoft MVP - Windows Server Networking Author: _Active Directory Consultant's Field Guide_ (http://tinyurl.com/7f8ll) Author: _Active Directory Cookbook, Second Edition_ (http://tinyurl.com/z7svl) 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 _ Try the new Live Search today! http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-usFORM=WLMTAG 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] Replication Problems and Tombstoned Objects
Ben,
We really need to find out exactly what was defined in the schema when to
determine how this occurred. From the information provided it would appear
that the groupofURLs class was defined in the schema and objects were
instantiated and then its definition was changed. This could explain why the
in-site DCs have the objects and out of site ones do not, schema partition
changes replicate at a higher priority than domain partition changes so when
these got bulked up for out of site replication the objects no longer met the
schema definition, i.e. the subclass of group is no longer defined for the
object. These objects do not appear to fit the definition of the groupofURLs
class as it is now defined and are therefore causing replication to be blocked.
This is of course all a hypothesis as I do not have the details on exactly
what changes were made when to the schema.
Thanks,
-Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN
Sent: Saturday, September 23, 2006 5:07 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Hi Steve,
Yes, there were some schema modifications one of the other admins was
working on to deploy an application that would allow for people to use
their Windows accounts to log into our Intrasite (they were formerly
using their Unix accounts). He had tested this on our test network,
which is a copy of our production network, upgraded to Windows 2003 R2
and also has the Longhorn schema extensions applied as well. From what
I understand, it experienced no ill effects, however it is a single site
test network.
Here is the output from the groupOfURLs extension.
AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED]) March 2006
Using server: appsig-av.appsig.com:389
Directory: Windows 2000
Base DN: CN=Schema,CN=Configuration,DC=appsig,DC=com
dn:CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
adminDisplayName: groupOfURLs
cn: groupOfURLs
defaultObjectCategory:
CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
governsID: 2.16.840.1.113730.3.2.33
instanceType: 4
lDAPDisplayName: groupOfURLs
mayContain: memberURL
distinguishedName:
CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
objectCategory:
CN=Class-Schema,CN=Schema,CN=Configuration,DC=appsig,DC=com
objectClass: top
objectClass: classSchema
objectClassCategory: 0
objectGUID: {2B09EA58-1A00-4170-B419-9ADC0AA0B655}
possSuperiors: container
name: groupOfURLs
rDNAttID: cn
schemaIDGUID: {8B5ACDC4-EAF2-45D9-A596-C196ABD02405}
showInAdvancedViewOnly: TRUE
subClassOf: top
systemOnly: FALSE
uSNChanged: 7985664
uSNCreated: 7985664
whenChanged: 20060913180400.0Z
whenCreated: 20060913180359.0Z
There are currently 4 other objects that have the groupofURLs listed as
an objectClass.
dn:CN=InfowebDept12,OU=InfowebGroups,DC=appsig,DC=com
objectClass: top
objectClass: groupOfURLs
objectClass: group
dn:CN=InfowebDept24,OU=InfowebGroups,DC=appsig,DC=com
objectClass: top
objectClass: groupOfURLs
objectClass: groupOfNames
objectClass: group
dn:CN=InfowebDept25,OU=InfowebGroups,DC=appsig,DC=com
objectClass: top
objectClass: groupOfURLs
objectClass: group
dn:CN=InfowebSection581,OU=InfowebGroups,DC=appsig,DC=com
objectClass: top
objectClass: groupOfURLs
objectClass: group
Let me know if you need anything else.
Thanks,
~Ben
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Linehan
Sent: Saturday, September 23, 2006 1:13 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Actually looking at this further you will probably find that the schemas
are in sync, i.e. the groupofURLs object class is defined across all of
the servers. I say that because the error you would have gotten if it
did not exist on the target would have been either schema mismatch or
ERROR_DS_OBJ_CLASS_NOT_DEFINED. So what I suspect is that groupofURLs
is not defined properly or is being referenced incorrectly. Can you
dump the schema entry for this class from one of your servers snd post
it? Also if you have the LDIF file that was used to update the schema
that includes the definition of this object class that would be great as
well. What I do not understand is how you have an object defined this
way as I would have expected us to block creation of the object if this
class is not defined/referenced properly. Any information on how the
schema was modified and how these objects were created would be helpful.
The fix will likely be to remove the groupofurls objectclass from the
object but you need to determine how you got to this point so that it
does not occur again.
Thanks,
-Steve
From: [EMAIL PROTECTED] On Behalf Of Steve Linehan
Sent: Saturday, September 23, 2006 2:54 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Ben,
Re: [ActiveDir] ADFS and certs
Joe, Tomasz - Yep, you're right that it may tend to show a bad precedent for people to follow. I haven't taken a look at these particular labs (and having just come back from a long hiatus, I didn't see the referenced lab) but is the guidance there as to what Best or Preferred Practices SHOULD BE? If not - I find that the bigger problem than the fact that self-certs are being used at all. Rick From: Tomasz Onyszko [EMAIL PROTECTED] Reply-To: ActiveDir@mail.activedir.org To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ADFS and certs Date: Sun, 24 Sep 2006 21:21:53 +0200 Joe Kaplan wrote: (...) I also think the ADFS step by step guide leads people down a dark path, in that all the demos are set up with selfssl and self-issued certs, which are ok for demos, but not cool for production (IMO) (...) Will jump with few word from myself again - I can agree on Your point regarding step by step in 100%. When I've tried to setup my first ADFS lab I've decided to use Windows 2003 CA instead of Self issued certs and for me it was far more natural way to use ADFS than this not-realistic SelfSSL scenario, which may be confusing for users. I've exchanged e-mail with peoples on internal mailing list few times about it and one good information is that this point was taken and updated version of step by step document for ADFS should be better on this. -- 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 _ The next generation of Search—say hello! http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-usFORM=WLMTAG 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] ADFS and certs
Rick Kingslan wrote: Joe, Tomasz - Yep, you're right that it may tend to show a bad precedent for people to follow. I haven't taken a look at these particular labs (and having just come back from a long hiatus, I didn't see the referenced lab) but is the guidance there as to what Best or Preferred Practices SHOULD BE? You can check this lab here: http://www.microsoft.com/downloads/details.aspx?familyid=062F7382-A82F-4428-9BBD-A103B9F27654displaylang=en No You will not find there any guidance on best practices there and maybe this is not the best place, but I'm not aware of any other ADFS related doc which deals in details with best practices and description of usage for certificates in ADFS deployment. If not - I find that the bigger problem than the fact that self-certs are being used at all. -- 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
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 to agree that LDAP does not define a good authentication protocol at all, it is definitely the case that LDAP is used as an
RE: [ActiveDir] Replication Problems and Tombstoned Objects
Steve,
So do you see anything obviously wrong that I could make a correction on
to repair replication? Also, is there anything I can follow up on in
regards to your comments about the objectclass being updated with a
value that is not a subclass? It's pretty obvious that the blockage is
origination from something about this now deleted object (
dn:CN=InfowebAccess\0ADEL:e988-616b-4944-bbe1-c8265cf4cc89,CN=Delete
d Objects,DC=appsig,DC=com). I just don't know what I can do with it at
this point.
C:\tools\err\Errerr 20b4
# for hex 0x20b4 / decimal 8372 :
ERROR_DS_OBJ_CLASS_NOT_SUBCLASS
winerror.h
# The specified class is not a subclass.
# 1 matches found for 20b4
I should be able to get more information for you tomorrow.
~Ben
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Linehan
Sent: Sunday, September 24, 2006 12:48 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Ben,
We really need to find out exactly what was defined in the schema when
to determine how this occurred. From the information provided it would
appear that the groupofURLs class was defined in the schema and objects
were instantiated and then its definition was changed. This could
explain why the in-site DCs have the objects and out of site ones do
not, schema partition changes replicate at a higher priority than domain
partition changes so when these got bulked up for out of site
replication the objects no longer met the schema definition, i.e. the
subclass of group is no longer defined for the object. These objects do
not appear to fit the definition of the groupofURLs class as it is now
defined and are therefore causing replication to be blocked. This is of
course all a hypothesis as I do not have the details on exactly what
changes were made when to the schema.
Thanks,
-Steve
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN
Sent: Saturday, September 23, 2006 5:07 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Hi Steve,
Yes, there were some schema modifications one of the other admins was
working on to deploy an application that would allow for people to use
their Windows accounts to log into our Intrasite (they were formerly
using their Unix accounts). He had tested this on our test network,
which is a copy of our production network, upgraded to Windows 2003 R2
and also has the Longhorn schema extensions applied as well. From what
I understand, it experienced no ill effects, however it is a single site
test network.
Here is the output from the groupOfURLs extension.
AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED]) March 2006
Using server: appsig-av.appsig.com:389
Directory: Windows 2000
Base DN: CN=Schema,CN=Configuration,DC=appsig,DC=com
dn:CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
adminDisplayName: groupOfURLs
cn: groupOfURLs
defaultObjectCategory:
CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
governsID: 2.16.840.1.113730.3.2.33
instanceType: 4
lDAPDisplayName: groupOfURLs
mayContain: memberURL
distinguishedName:
CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
objectCategory:
CN=Class-Schema,CN=Schema,CN=Configuration,DC=appsig,DC=com
objectClass: top
objectClass: classSchema
objectClassCategory: 0
objectGUID: {2B09EA58-1A00-4170-B419-9ADC0AA0B655}
possSuperiors: container
name: groupOfURLs
rDNAttID: cn
schemaIDGUID: {8B5ACDC4-EAF2-45D9-A596-C196ABD02405}
showInAdvancedViewOnly: TRUE
subClassOf: top
systemOnly: FALSE
uSNChanged: 7985664
uSNCreated: 7985664
whenChanged: 20060913180400.0Z
whenCreated: 20060913180359.0Z
There are currently 4 other objects that have the groupofURLs listed as
an objectClass.
dn:CN=InfowebDept12,OU=InfowebGroups,DC=appsig,DC=com
objectClass: top
objectClass: groupOfURLs
objectClass: group
dn:CN=InfowebDept24,OU=InfowebGroups,DC=appsig,DC=com
objectClass: top
objectClass: groupOfURLs
objectClass: groupOfNames
objectClass: group
dn:CN=InfowebDept25,OU=InfowebGroups,DC=appsig,DC=com
objectClass: top
objectClass: groupOfURLs
objectClass: group
dn:CN=InfowebSection581,OU=InfowebGroups,DC=appsig,DC=com
objectClass: top
objectClass: groupOfURLs
objectClass: group
Let me know if you need anything else.
Thanks,
~Ben
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Linehan
Sent: Saturday, September 23, 2006 1:13 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Actually looking at this further you will probably find that the schemas
are in sync, i.e. the groupofURLs object class is defined across all of
the servers. I say that because the error you would have gotten if it
did not exist on the target would have been either schema mismatch or
ERROR_DS_OBJ_CLASS_NOT_DEFINED. So what I suspect is that groupofURLs
is not
Re: [ActiveDir] ADFS and certs
Yeah, the real step by step guide isn't so bad per say. What it tries to do is give you a simple path to having an easy demo set up of ADFS going so you can kick the tires. For that, it is ok. Where it doesn't cross the gap very well is in providing guidance on how to apply the lessons learned to real scenarios. Because ADFS relies on certificates for both SSL/HTTP and the signing of security tokens, you need certificates to use it. In order to get through the step by step guide successfully, they chose to use the self-issued model, as it is really the only simple way to get SSL certs without spending money or setting up a CA. However, it does leave you with self-signed certs, which is not where you want to end up. I think that either the step by step guide needs to provide more guidance and explanation of the steps and how to apply them, or the other documentation for ADFS needs to fill this gap. As it stands now, there is still no good guidance on how to procure your certificates and what the various trade-offs are for the possible ways to go about this. People who already know PKI will be able to fill in the details, but many people will be left scratching their heads. Perhaps Tomasz and I should blog about this more for now. :) Joe K. - Original Message - From: Tomasz Onyszko [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Sunday, September 24, 2006 3:16 PM Subject: Re: [ActiveDir] ADFS and certs Rick Kingslan wrote: Joe, Tomasz - Yep, you're right that it may tend to show a bad precedent for people to follow. I haven't taken a look at these particular labs (and having just come back from a long hiatus, I didn't see the referenced lab) but is the guidance there as to what Best or Preferred Practices SHOULD BE? You can check this lab here: http://www.microsoft.com/downloads/details.aspx?familyid=062F7382-A82F-4428-9BBD-A103B9F27654displaylang=en No You will not find there any guidance on best practices there and maybe this is not the best place, but I'm not aware of any other ADFS related doc which deals in details with best practices and description of usage for certificates in ADFS deployment. If not - I find that the bigger problem than the fact that self-certs are being used at all. -- 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
[ActiveDir] OT (sorta) ILO's and OUs
http://h2.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c00756037jumpid=em_EL_Alerts/US/Sep06_ALL/Alerts For additional information and specific instructions, refer to the document /Integrating HP ProLiant Lights-Out processors with Microsoft Active Directory, /available at the following URL: http://h2.www2.hp.com/bc/docs/support/SupportManual/c00190541/c00190541.pdf 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] Replication Problems and Tombstoned Objects
Ben,
I believe all of the objects of this class will cause the same problem
because it appears they were created and the schema was changed after they were
instantiated. One way to correct the problem may be to add back group and
groupOfNames classes to the groupofURLs schema definition. I would of course
test doing this first and also follow up with whoever was responsible for the
original schema change to determine exactly what they did which would allow you
to reverse the changes. If you were on Windows Server 2003 and in Forest
Functional Level 2, i.e. Windows 2003 Forest Functional Level, you could have
defunct the schema change.
Thanks,
-Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN
Sent: Sunday, September 24, 2006 3:50 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Steve,
So do you see anything obviously wrong that I could make a correction on
to repair replication? Also, is there anything I can follow up on in
regards to your comments about the objectclass being updated with a
value that is not a subclass? It's pretty obvious that the blockage is
origination from something about this now deleted object (
dn:CN=InfowebAccess\0ADEL:e988-616b-4944-bbe1-c8265cf4cc89,CN=Delete
d Objects,DC=appsig,DC=com). I just don't know what I can do with it at
this point.
C:\tools\err\Errerr 20b4
# for hex 0x20b4 / decimal 8372 :
ERROR_DS_OBJ_CLASS_NOT_SUBCLASS
winerror.h
# The specified class is not a subclass.
# 1 matches found for 20b4
I should be able to get more information for you tomorrow.
~Ben
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Linehan
Sent: Sunday, September 24, 2006 12:48 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Ben,
We really need to find out exactly what was defined in the schema when
to determine how this occurred. From the information provided it would
appear that the groupofURLs class was defined in the schema and objects
were instantiated and then its definition was changed. This could
explain why the in-site DCs have the objects and out of site ones do
not, schema partition changes replicate at a higher priority than domain
partition changes so when these got bulked up for out of site
replication the objects no longer met the schema definition, i.e. the
subclass of group is no longer defined for the object. These objects do
not appear to fit the definition of the groupofURLs class as it is now
defined and are therefore causing replication to be blocked. This is of
course all a hypothesis as I do not have the details on exactly what
changes were made when to the schema.
Thanks,
-Steve
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN
Sent: Saturday, September 23, 2006 5:07 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Hi Steve,
Yes, there were some schema modifications one of the other admins was
working on to deploy an application that would allow for people to use
their Windows accounts to log into our Intrasite (they were formerly
using their Unix accounts). He had tested this on our test network,
which is a copy of our production network, upgraded to Windows 2003 R2
and also has the Longhorn schema extensions applied as well. From what
I understand, it experienced no ill effects, however it is a single site
test network.
Here is the output from the groupOfURLs extension.
AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED]) March 2006
Using server: appsig-av.appsig.com:389
Directory: Windows 2000
Base DN: CN=Schema,CN=Configuration,DC=appsig,DC=com
dn:CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
adminDisplayName: groupOfURLs
cn: groupOfURLs
defaultObjectCategory:
CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
governsID: 2.16.840.1.113730.3.2.33
instanceType: 4
lDAPDisplayName: groupOfURLs
mayContain: memberURL
distinguishedName:
CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
objectCategory:
CN=Class-Schema,CN=Schema,CN=Configuration,DC=appsig,DC=com
objectClass: top
objectClass: classSchema
objectClassCategory: 0
objectGUID: {2B09EA58-1A00-4170-B419-9ADC0AA0B655}
possSuperiors: container
name: groupOfURLs
rDNAttID: cn
schemaIDGUID: {8B5ACDC4-EAF2-45D9-A596-C196ABD02405}
showInAdvancedViewOnly: TRUE
subClassOf: top
systemOnly: FALSE
uSNChanged: 7985664
uSNCreated: 7985664
whenChanged: 20060913180400.0Z
whenCreated: 20060913180359.0Z
There are currently 4 other objects that have the groupofURLs listed as
an objectClass.
dn:CN=InfowebDept12,OU=InfowebGroups,DC=appsig,DC=com
objectClass: top
objectClass: groupOfURLs
objectClass: group
dn:CN=InfowebDept24,OU=InfowebGroups,DC=appsig,DC=com
objectClass: top
objectClass: groupOfURLs
objectClass: groupOfNames
RE: [ActiveDir] Replication Problems and Tombstoned Objects
Hi Steve,
Just to make sure I understand, do you mean I should add back group and
groupOfNames as a maycontain to the groupofURLs objectclass?
Thanks,
~Ben
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Linehan
Sent: Sunday, September 24, 2006 8:04 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Ben,
I believe all of the objects of this class will cause the same problem
because it appears they were created and the schema was changed after
they were instantiated. One way to correct the problem may be to add
back group and groupOfNames classes to the groupofURLs schema
definition. I would of course test doing this first and also follow up
with whoever was responsible for the original schema change to determine
exactly what they did which would allow you to reverse the changes. If
you were on Windows Server 2003 and in Forest Functional Level 2, i.e.
Windows 2003 Forest Functional Level, you could have defunct the schema
change.
Thanks,
-Steve
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN
Sent: Sunday, September 24, 2006 3:50 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Steve,
So do you see anything obviously wrong that I could make a correction on
to repair replication? Also, is there anything I can follow up on in
regards to your comments about the objectclass being updated with a
value that is not a subclass? It's pretty obvious that the blockage is
origination from something about this now deleted object (
dn:CN=InfowebAccess\0ADEL:e988-616b-4944-bbe1-c8265cf4cc89,CN=Delete
d Objects,DC=appsig,DC=com). I just don't know what I can do with it at
this point.
C:\tools\err\Errerr 20b4
# for hex 0x20b4 / decimal 8372 :
ERROR_DS_OBJ_CLASS_NOT_SUBCLASS
winerror.h
# The specified class is not a subclass.
# 1 matches found for 20b4
I should be able to get more information for you tomorrow.
~Ben
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Linehan
Sent: Sunday, September 24, 2006 12:48 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Ben,
We really need to find out exactly what was defined in the schema when
to determine how this occurred. From the information provided it would
appear that the groupofURLs class was defined in the schema and objects
were instantiated and then its definition was changed. This could
explain why the in-site DCs have the objects and out of site ones do
not, schema partition changes replicate at a higher priority than domain
partition changes so when these got bulked up for out of site
replication the objects no longer met the schema definition, i.e. the
subclass of group is no longer defined for the object. These objects do
not appear to fit the definition of the groupofURLs class as it is now
defined and are therefore causing replication to be blocked. This is of
course all a hypothesis as I do not have the details on exactly what
changes were made when to the schema.
Thanks,
-Steve
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN
Sent: Saturday, September 23, 2006 5:07 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects
Hi Steve,
Yes, there were some schema modifications one of the other admins was
working on to deploy an application that would allow for people to use
their Windows accounts to log into our Intrasite (they were formerly
using their Unix accounts). He had tested this on our test network,
which is a copy of our production network, upgraded to Windows 2003 R2
and also has the Longhorn schema extensions applied as well. From what
I understand, it experienced no ill effects, however it is a single site
test network.
Here is the output from the groupOfURLs extension.
AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED]) March 2006
Using server: appsig-av.appsig.com:389
Directory: Windows 2000
Base DN: CN=Schema,CN=Configuration,DC=appsig,DC=com
dn:CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
adminDisplayName: groupOfURLs
cn: groupOfURLs
defaultObjectCategory:
CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
governsID: 2.16.840.1.113730.3.2.33
instanceType: 4
lDAPDisplayName: groupOfURLs
mayContain: memberURL
distinguishedName:
CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com
objectCategory:
CN=Class-Schema,CN=Schema,CN=Configuration,DC=appsig,DC=com
objectClass: top
objectClass: classSchema
objectClassCategory: 0
objectGUID: {2B09EA58-1A00-4170-B419-9ADC0AA0B655}
possSuperiors: container
name: groupOfURLs
rDNAttID: cn
schemaIDGUID: {8B5ACDC4-EAF2-45D9-A596-C196ABD02405}
showInAdvancedViewOnly: TRUE
subClassOf: top
systemOnly: FALSE
uSNChanged: 7985664
uSNCreated:
RE: [ActiveDir] Replication Problems and Tombstoned Objects
Yes. Thanks, -Steve -Original Message- From: WATSON, BEN [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: 9/24/06 11:21 PM Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects Hi Steve, Just to make sure I understand, do you mean I should add back group and groupOfNames as a maycontain to the groupofURLs objectclass? Thanks, ~Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Linehan Sent: Sunday, September 24, 2006 8:04 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects Ben, I believe all of the objects of this class will cause the same problem because it appears they were created and the schema was changed after they were instantiated. One way to correct the problem may be to add back group and groupOfNames classes to the groupofURLs schema definition. I would of course test doing this first and also follow up with whoever was responsible for the original schema change to determine exactly what they did which would allow you to reverse the changes. If you were on Windows Server 2003 and in Forest Functional Level 2, i.e. Windows 2003 Forest Functional Level, you could have defunct the schema change. Thanks, -Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN Sent: Sunday, September 24, 2006 3:50 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects Steve, So do you see anything obviously wrong that I could make a correction on to repair replication? Also, is there anything I can follow up on in regards to your comments about the objectclass being updated with a value that is not a subclass? It's pretty obvious that the blockage is origination from something about this now deleted object ( dn:CN=InfowebAccess\0ADEL:e988-616b-4944-bbe1-c8265cf4cc89,CN=Delete d Objects,DC=appsig,DC=com). I just don't know what I can do with it at this point. C:\tools\err\Errerr 20b4 # for hex 0x20b4 / decimal 8372 : ERROR_DS_OBJ_CLASS_NOT_SUBCLASS winerror.h # The specified class is not a subclass. # 1 matches found for 20b4 I should be able to get more information for you tomorrow. ~Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Linehan Sent: Sunday, September 24, 2006 12:48 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects Ben, We really need to find out exactly what was defined in the schema when to determine how this occurred. From the information provided it would appear that the groupofURLs class was defined in the schema and objects were instantiated and then its definition was changed. This could explain why the in-site DCs have the objects and out of site ones do not, schema partition changes replicate at a higher priority than domain partition changes so when these got bulked up for out of site replication the objects no longer met the schema definition, i.e. the subclass of group is no longer defined for the object. These objects do not appear to fit the definition of the groupofURLs class as it is now defined and are therefore causing replication to be blocked. This is of course all a hypothesis as I do not have the details on exactly what changes were made when to the schema. Thanks, -Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN Sent: Saturday, September 23, 2006 5:07 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Replication Problems and Tombstoned Objects Hi Steve, Yes, there were some schema modifications one of the other admins was working on to deploy an application that would allow for people to use their Windows accounts to log into our Intrasite (they were formerly using their Unix accounts). He had tested this on our test network, which is a copy of our production network, upgraded to Windows 2003 R2 and also has the Longhorn schema extensions applied as well. From what I understand, it experienced no ill effects, however it is a single site test network. Here is the output from the groupOfURLs extension. AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED]) March 2006 Using server: appsig-av.appsig.com:389 Directory: Windows 2000 Base DN: CN=Schema,CN=Configuration,DC=appsig,DC=com dn:CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com adminDisplayName: groupOfURLs cn: groupOfURLs defaultObjectCategory: CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com governsID: 2.16.840.1.113730.3.2.33 instanceType: 4 lDAPDisplayName: groupOfURLs mayContain: memberURL distinguishedName: CN=groupOfURLs,CN=Schema,CN=Configuration,DC=appsig,DC=com objectCategory: CN=Class-Schema,CN=Schema,CN=Configuration,DC=appsig,DC=com objectClass: top objectClass: classSchema objectClassCategory: 0 objectGUID:
