List Archives

This forum is an archive of all posts to our mailing list over the past few years. The forum is set read only therefore to contribute you will need to join our list community. See more info about this here.

When subscribed to the list you should use your standard email client to send your posts to ActiveDir@mail.activedir.org.

List Archives

Unanswered Active Topics

Forums Search

Forums >ActiveDir Mail List Archive >List Archives

Subject: [ActiveDir] Read-Only Domain Controller and Server Core

Prev Next

You are not authorized to post a reply.

Page 4 of 4

Author

Messages

listmail

Posts:824

07/31/2006 10:25 AM
No, if you see Nathan in a McDonald's restaurant, please, ask for his autograph. That is fine, he will probably grin and laugh, he is a great guy. Anyway, he obviously isn't working if he is hanging out there so getting his autograph is fine. However, don't email him and take him away from his very important work because if he is in front of a computer to read your email, chances are, he is working. :) Mostly I just wanted to point out to the list denizens who maybe don't know names that we have some pretty heavy hitters lurking on this list so if they ever think it is a waste to post what they think is wrong with AD or the Domain Environment or ADAM or what not, they shouldn't think that. This is one of the best places to post it because actual Developers/PMs like Dmitri/Nathan, people who care greatly but aren't directly on the Dev team like ~Eric and Brian, and general purpose rock stars like Stuart Kwan of the Ottawa Kwan Clan are reading this list. I expect they are mostly avoiding my rants but they do watch for certain topics. Something like RODC and Server Core certainly will catch their attention at the moment obviously. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura A. RobinsonSent: Monday, July 31, 2006 4:30 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Joe, isn't the below kind of like yelling, "OMG! Elvis!" in a McDonald's restaurant in Kalamazoo and following it up with, "nobody ask for his autograph"? ;-) Laura From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joeSent: Monday, July 31, 2006 3:13 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Whoa... Nathan too. This list is hopping... For those folks who don't know Nathan... Read his signature carefully and realize the level of people this list is seen by. And don't email him directly unless you found a world ending issue with Longhorn DCs, he is a busy guy about right now. :) I could easily bother Nathan with about 40 emails a day but try to leave him completely alone. All I say is if this stuff is implemented, please please please please have the details in the Platform SDK ASAP. Actualy flag values and meanings and caveates and everything else. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Nathan MuggliSent: Monday, July 31, 2006 12:18 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core We thought about using the confidential flag as the denotation for the RO-PAS, but that would break too many applications. The RO-PAS would only be for applications that wanted to protect their secrets from replicating to a RODC. DIMS (aka cred roaming) is a prime example. Most likely if RO-PAS happens it will be a negative PAS in that the marking in the schema would mean that the attr is NOT replicated. That way new vanilla attributes are replicated to a RODC which would minimize app compat. -Nathan Muggli RODC Program Manager From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, GuidoSent: Monday, July 31, 2006 1:35 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Not sure if it makes sense, but this could potentially be combined with the confidential flag “ RODCs wouldn™t cache any confidential attributes, unless a Confidential Data Caching Policy would allow them to do so¦ The confidential flag is already used by the Digital Identity Management Service (DIMS) for the Credential Roaming feature. And instead of adding yet another flag to differentiate attributes which contain secrets or sensitive data, this may just be the right flag. Granted, none of this will make life easier for app developers. /Guido From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brian PuhlSent: Monday, July 31, 2006 10:05 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core You™re right Joe “ that the RODC PAS would complicate things for the developers. The easy solution would be for developers to use the writeable flag when connecting to a DC, then they™d be guaranteed to not get an RODC¦but even that isn™t a great solution, and if we get the RODC GC it only becomes more complex. For general background though, the justification for the RODC PAS DCR is actually that there are numerous attributes which contain password hash, or password-like data. Because these attributes aren™t part of the pre-defined list of secrets, they are replicated normally rather than on-demand via the PRP. It wouldn™t do me much good to prevent replication of 5 password attributes, when a 6th one which also includes a hash gets pushed down through normal replication. There needs to be a way for an administrator to define where these secrets live and protect them accordingly. I™ve broached the topic of using this method to protect PII data a couple of times in relation to some RODC work we™re doing internally, and the response is always that it™s firmly in the realm of unsupported followed with a that™d be a bad idea and some serious head shaking “ simply because of the way applications behave. Brian From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joeSent: Sunday, July 30, 2006 5:08 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core I am not sure if I understand where you are going but let me explain where I am coming from. First, the passwords being there or not being there is not important for this talk, that is already built in and will be there, now the discussion is around everything versus an RODC PAS. Everything is already there as well but is an important option because it will be the most used option. Actually I expect to see a ton of RODCs deployed that are configured as replicate everything including passwords so that people get the RO part of the benefit and they don't have to worry about replicating bad stuff back into the "real directory" and not have to worry about password caching management, if someone logs on somewhere, the password is cached there, bob's your uncle have a nice day. So now we get down to replicating a portion of the normal attribute set. Why would you want to do this? Because you want to minimize the traffic to WAN sites and/or reduced info in some locations in case of compromise. For instance, if the email addresses of everyone in the company isn't on a DC in a WAN site and someone steals that DC hoping to get those email addresses, they are SOL; they missed. However, now think about this from a application developer standpoint and it is the same issue that exists with GCs only worse because it is DCs. If an app developer wants to find something, they need to understand what they can actually find in the GC in terms of what attributes are populated. Maybe they (a) put in a requirement and hope people follow it, maybe they (b) actually try to verify it, maybe they (c) say screw that and query a DC instead because they know all of the data is there for a full query. >From what I have seen the likely cases for an app that can handle any query is C, A, and in the absolute blue moon case B. Usually the app will just fail to find what it needs if you specify an attribute that isn't in the GC. How does Exchange do it??? So there are hybrids like where certain things that people KNOW will always be in GC PAS and they will set it up so that queries using those things will use a GC and everything else will go to a DC. We already know that the same override that exists for the GC PAS would have to exist for an RODC PAS so why not just make that the other option and be done with it? I don't really see the majority of developers doing this any better with RODCs than they do with GCs and so it seems like a lot of make work to allow for the flexible handling of that if you just say these are the options. Again also the password thing isn't even worried about at the app level since apps can play with those anyway. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent: Sunday, July 30, 2006 6:57 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] Read-Only Domain Controller and Server Core Um, why? What value at this point? Last I checked it supports limited applications that might want that information. And if you follow ~Eric's logic, they want to be secure out of the box. That would indicate that they want it to be as minimal as possible until and unless told otherwise. To put that information in there by default might be counter to that. Now, if you had some templates or something so that we didn't have to work on the carpal tunnel, that would be something....:) On 7/30/06, joe listmail@xxxxxxxxxxx> wrote: RE: RODC PAS.... Oi, that will add some nice complexity to all of this... :) If I was looking to implement that I think I would look at doing it in four levels so people don't shoot themselves... Everything, everything but password info, core NOS info required for auth/authz with passwords, core NOS w/o passwords. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dmitri GavrilovSent: Friday, July 28, 2006 12:48 PM To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core The set of passwords that can be sent down to the RODC is controlled by password replication policy. The passwords are sent down by RODC's request, but the hub also checks whether the user (whose pwd is being requested) actually attempted to authenticate at RODC (the hub can induce this info from the traffic is sees). The pwd hash is sent down only if both are satisfied: pwd policy allows it and the user actually attempted to logon there. Pwd policy is "empty" by default, i.e. nobody is in "allowed to reveal" list. It is admin's responsibility to populate this list. We might have some UI that helps with this process. Once the hash is sent down, there's no way to remove it from RODC, basically because we do not trust that RODC will remove it, even if instructed to do so. Therefore, the only way to "expire" the hash is to change the password. We store the list of passwords that were sent down to RODC in an attribute on the RODC computer object (the hub DC updates the list when it sends a pwd). So, if the RODC is stolen, you can enumerate whose passwords were down there, and make these users reset their passwords. There's a constructed attribute that returns only the users whose * current* passwords appear to be on the RODC. WRT what data is sent down “ currently, we send everything, sans a handful of "secret" attributes, which are controlled by pwd replication policy. There's a DCR to be able to configure the list of attributes that can go down to RODC (aka RODC PAS), but it is not yet clear if we will get it done or not. Note that the client data access story on RODC becomes quite convoluted because you don't know if you are seeing the whole object or only a subset of it. We do not normally issue referrals due to "partial reads". From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of neil.ruston@xxxxxxxxxxxxxSent: Friday, July 28, 2006 8:22 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core RODC stores password hashes only for a pre defined list of users and they are not stored on a permanent basis. [I'm unclear how the latter is achieved.] The goal is such that if the RODC were removed from the office then no password secrets could be extracted from that machine. neil From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent: 28 July 2006 16:08To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] Read-Only Domain Controller and Server Core The part that makes me wonder about the "story" is if it stores no secrets is the server doing anything for me? Is there a point to deploying the server in a remote office other than just being able to point to it in the closet and say, "see, I do to earn my paycheck!" I'm sure there's more, but I don't yet know which parts are public information and which are NDA. Can you tell I'm concerned about the story being created? I like stories; don't get me wrong. But I'm concerned that the story being spun up might be missing the mark and lead a few people astray. Safe to note that there are some features that differentiate the RODC from a NT4 BDC and that make it appealing in some cases. But if it actually does not store anything locally, ever, then I'm not sure it's worth the time to deploy one now is it? Al On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] sbradcpa@xxxxxxxxxxx> wrote: FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx Read-Only Domain Controller and Server CoreList info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email please notify the sender immediately and delete your copy from your system. You must not copy, distribute or take any further action in reliance on it. Email is not a secure method of communication and Nomura International plc ('NIplc') will not, to the extent permitted by law, accept responsibility or liability for (a) the accuracy or completeness of, or (b) the presence of any virus, worm or similar malicious or disabling code in, this message or any attachment(s) to it. If verification of this email is sought then please request a hard copy. Unless otherwise stated this email: (1) is not, and should not be treated or relied upon as, investment research; (2) contains views or opinions that are solely those of the author and do not necessarily represent those of NIplc; (3) is intended for informational purposes only and is not a recommendation, solicitation or offer to buy or sell securities or related financial instruments. NIplc does not provide investment services to private customers. Authorised and regulated by the Financial Services Authority. Registered in England no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand, London, EC1A 4NP. A member of the Nomura group of companies.

listmail

Posts:824

07/31/2006 12:07 PM
I am not sure if I understand where you are going but let me explain where I am coming from. First, the passwords being there or not being there is not important for this talk, that is already built in and will be there, now the discussion is around everything versus an RODC PAS. Everything is already there as well but is an important option because it will be the most used option. Actually I expect to see a ton of RODCs deployed that are configured as replicate everything including passwords so that people get the RO part of the benefit and they don't have to worry about replicating bad stuff back into the "real directory" and not have to worry about password caching management, if someone logs on somewhere, the password is cached there, bob's your uncle have a nice day. So now we get down to replicating a portion of the normal attribute set. Why would you want to do this? Because you want to minimize the traffic to WAN sites and/or reduced info in some locations in case of compromise. For instance, if the email addresses of everyone in the company isn't on a DC in a WAN site and someone steals that DC hoping to get those email addresses, they are SOL; they missed. However, now think about this from a application developer standpoint and it is the same issue that exists with GCs only worse because it is DCs. If an app developer wants to find something, they need to understand what they can actually find in the GC in terms of what attributes are populated. Maybe they (a) put in a requirement and hope people follow it, maybe they (b) actually try to verify it, maybe they (c) say screw that and query a DC instead because they know all of the data is there for a full query. From what I have seen the likely cases for an app that can handle any query is C, A, and in the absolute blue moon case B. Usually the app will just fail to find what it needs if you specify an attribute that isn't in the GC. How does Exchange do it??? So there are hybrids like where certain things that people KNOW will always be in GC PAS and they will set it up so that queries using those things will use a GC and everything else will go to a DC. We already know that the same override that exists for the GC PAS would have to exist for an RODC PAS so why not just make that the other option and be done with it? I don't really see the majority of developers doing this any better with RODCs than they do with GCs and so it seems like a lot of make work to allow for the flexible handling of that if you just say these are the options. Again also the password thing isn't even worried about at the app level since apps can play with those anyway. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent: Sunday, July 30, 2006 6:57 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] Read-Only Domain Controller and Server Core Um, why? What value at this point? Last I checked it supports limited applications that might want that information. And if you follow ~Eric's logic, they want to be secure out of the box. That would indicate that they want it to be as minimal as possible until and unless told otherwise. To put that information in there by default might be counter to that. Now, if you had some templates or something so that we didn't have to work on the carpal tunnel, that would be something....:) On 7/30/06, joe wrote: RE: RODC PAS.... Oi, that will add some nice complexity to all of this... :) If I was looking to implement that I think I would look at doing it in four levels so people don't shoot themselves... Everything, everything but password info, core NOS info required for auth/authz with passwords, core NOS w/o passwords. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dmitri GavrilovSent: Friday, July 28, 2006 12:48 PM To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core The set of passwords that can be sent down to the RODC is controlled by password replication policy. The passwords are sent down by RODC's request, but the hub also checks whether the user (whose pwd is being requested) actually attempted to authenticate at RODC (the hub can induce this info from the traffic is sees). The pwd hash is sent down only if both are satisfied: pwd policy allows it and the user actually attempted to logon there. Pwd policy is "empty" by default, i.e. nobody is in "allowed to reveal" list. It is admin's responsibility to populate this list. We might have some UI that helps with this process. Once the hash is sent down, there's no way to remove it from RODC, basically because we do not trust that RODC will remove it, even if instructed to do so. Therefore, the only way to "expire" the hash is to change the password. We store the list of passwords that were sent down to RODC in an attribute on the RODC computer object (the hub DC updates the list when it sends a pwd). So, if the RODC is stolen, you can enumerate whose passwords were down there, and make these users reset their passwords. There's a constructed attribute that returns only the users whose * current* passwords appear to be on the RODC. WRT what data is sent down “ currently, we send everything, sans a handful of "secret" attributes, which are controlled by pwd replication policy. There's a DCR to be able to configure the list of attributes that can go down to RODC (aka RODC PAS), but it is not yet clear if we will get it done or not. Note that the client data access story on RODC becomes quite convoluted because you don't know if you are seeing the whole object or only a subset of it. We do not normally issue referrals due to "partial reads". From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of neil.ruston@xxxxxxxxxxxxxSent: Friday, July 28, 2006 8:22 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core RODC stores password hashes only for a pre defined list of users and they are not stored on a permanent basis. [I'm unclear how the latter is achieved.] The goal is such that if the RODC were removed from the office then no password secrets could be extracted from that machine. neil From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent: 28 July 2006 16:08To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] Read-Only Domain Controller and Server Core The part that makes me wonder about the "story" is if it stores no secrets is the server doing anything for me? Is there a point to deploying the server in a remote office other than just being able to point to it in the closet and say, "see, I do to earn my paycheck!" I'm sure there's more, but I don't yet know which parts are public information and which are NDA. Can you tell I'm concerned about the story being created? I like stories; don't get me wrong. But I'm concerned that the story being spun up might be missing the mark and lead a few people astray. Safe to note that there are some features that differentiate the RODC from a NT4 BDC and that make it appealing in some cases. But if it actually does not store anything locally, ever, then I'm not sure it's worth the time to deploy one now is it? Al On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] sbradcpa@xxxxxxxxxxx> wrote: FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx Read-Only Domain Controller and Server CoreList info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email please notify the sender immediately and delete your copy from your system. You must not copy, distribute or take any further action in reliance on it. Email is not a secure method of communication and Nomura International plc ('NIplc') will not, to the extent permitted by law, accept responsibility or liability for (a) the accuracy or completeness of, or (b) the presence of any virus, worm or similar malicious or disabling code in, this message or any attachment(s) to it. If verification of this email is sought then please request a hard copy. Unless otherwise stated this email: (1) is not, and should not be treated or relied upon as, investment research; (2) contains views or opinions that are solely those of the author and do not necessarily represent those of NIplc; (3) is intended for informational purposes only and is not a recommendation, solicitation or offer to buy or sell securities or related financial instruments. NIplc does not provide investment services to private customers. Authorised and regulated by the Financial Services Authority. Registered in England no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand, London, EC1A 4NP. A member of the Nomura group of companies.

listmail

Posts:824

listmail

Posts:824

08/01/2006 12:30 PM
Certainly I know of a couple of customers who could immediately make use of it in exactly that way right now. The first thing I would be doing once that feature hit is finding out how much I could strip out and then find ways to strip out even more because honestly, most of that Cat-1 base schema stuff really isn't necessary everywhere. :) -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David AdnerSent: Monday, July 31, 2006 5:56 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core The Netware partial-replica model immediately jumped to mind when the RODC-PAS idea was broached. I can see a lot of customers trying to use this feature to create partial-replicas way beyond concerns of preventing replication of sensitive data. I suppose one big difference (making an assumption here) is the RODC-PAS will be global and not specific to each RODC. Still, I can see customers wanting to "strip out" all sorts of data they don't feel needs to be in the branches in order to reduce WAN utilization, database sizes, memory consumption, etc. Based on personal experience this would probably be a more common reason to deploy an RODC than concerns about physical security (not that I agree with them, of course). From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joeSent: Monday, July 31, 2006 1:53 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Hey Brian, good to see your name on the list... I got pinged offline on the basis behind this functionality. I admit to being a little shocked that someone was tossing password type info into other attributes especially with AD being so generally open to viewing, especially when using the Pre-W2K Compat group with auth'ed users allowed to see all attributes by default which most domains still seem to be in due to fears in what will break if it is turned off. If this is purely based on security concerns, I would be more apt to tell people to install ADAM on the DCs and put the data there. At least you know that is severely locked down by default and not having to be worried what side direction someone might come in and pop you from. From the standpoint of less crap being sent down to WAN DCs I like the idea. I realize I can't have branch level replication but at least being able to weed out all of the non-essential attributes would be a nice start for tiny branches with 10 users in domains with tens of thousands of users. I actually recently had to say it didn't make any sense to move from Novell to AD for a customer because of that very issue. You can't imagine how much that pained me to say. In cases like that if there is no real strategic reason to move to AD, it is better to stay on Novell because of the replication model. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brian PuhlSent: Monday, July 31, 2006 4:05 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core You™re right Joe “ that the RODC PAS would complicate things for the developers. The easy solution would be for developers to use the writeable flag when connecting to a DC, then they™d be guaranteed to not get an RODC¦but even that isn™t a great solution, and if we get the RODC GC it only becomes more complex. For general background though, the justification for the RODC PAS DCR is actually that there are numerous attributes which contain password hash, or password-like data. Because these attributes aren™t part of the pre-defined list of secrets, they are replicated normally rather than on-demand via the PRP. It wouldn™t do me much good to prevent replication of 5 password attributes, when a 6th one which also includes a hash gets pushed down through normal replication. There needs to be a way for an administrator to define where these secrets live and protect them accordingly. I™ve broached the topic of using this method to protect PII data a couple of times in relation to some RODC work we™re doing internally, and the response is always that it™s firmly in the realm of unsupported followed with a that™d be a bad idea and some serious head shaking “ simply because of the way applications behave. Brian From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joeSent: Sunday, July 30, 2006 5:08 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core I am not sure if I understand where you are going but let me explain where I am coming from. First, the passwords being there or not being there is not important for this talk, that is already built in and will be there, now the discussion is around everything versus an RODC PAS. Everything is already there as well but is an important option because it will be the most used option. Actually I expect to see a ton of RODCs deployed that are configured as replicate everything including passwords so that people get the RO part of the benefit and they don't have to worry about replicating bad stuff back into the "real directory" and not have to worry about password caching management, if someone logs on somewhere, the password is cached there, bob's your uncle have a nice day. So now we get down to replicating a portion of the normal attribute set. Why would you want to do this? Because you want to minimize the traffic to WAN sites and/or reduced info in some locations in case of compromise. For instance, if the email addresses of everyone in the company isn't on a DC in a WAN site and someone steals that DC hoping to get those email addresses, they are SOL; they missed. However, now think about this from a application developer standpoint and it is the same issue that exists with GCs only worse because it is DCs. If an app developer wants to find something, they need to understand what they can actually find in the GC in terms of what attributes are populated. Maybe they (a) put in a requirement and hope people follow it, maybe they (b) actually try to verify it, maybe they (c) say screw that and query a DC instead because they know all of the data is there for a full query. From what I have seen the likely cases for an app that can handle any query is C, A, and in the absolute blue moon case B. Usually the app will just fail to find what it needs if you specify an attribute that isn't in the GC. How does Exchange do it??? So there are hybrids like where certain things that people KNOW will always be in GC PAS and they will set it up so that queries using those things will use a GC and everything else will go to a DC. We already know that the same override that exists for the GC PAS would have to exist for an RODC PAS so why not just make that the other option and be done with it? I don't really see the majority of developers doing this any better with RODCs than they do with GCs and so it seems like a lot of make work to allow for the flexible handling of that if you just say these are the options. Again also the password thing isn't even worried about at the app level since apps can play with those anyway. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent: Sunday, July 30, 2006 6:57 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] Read-Only Domain Controller and Server Core Um, why? What value at this point? Last I checked it supports limited applications that might want that information. And if you follow ~Eric's logic, they want to be secure out of the box. That would indicate that they want it to be as minimal as possible until and unless told otherwise. To put that information in there by default might be counter to that. Now, if you had some templates or something so that we didn't have to work on the carpal tunnel, that would be something....:) On 7/30/06, joe listmail@xxxxxxxxxxx> wrote: RE: RODC PAS.... Oi, that will add some nice complexity to all of this... :) If I was looking to implement that I think I would look at doing it in four levels so people don't shoot themselves... Everything, everything but password info, core NOS info required for auth/authz with passwords, core NOS w/o passwords. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dmitri GavrilovSent: Friday, July 28, 2006 12:48 PM To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core The set of passwords that can be sent down to the RODC is controlled by password replication policy. The passwords are sent down by RODC's request, but the hub also checks whether the user (whose pwd is being requested) actually attempted to authenticate at RODC (the hub can induce this info from the traffic is sees). The pwd hash is sent down only if both are satisfied: pwd policy allows it and the user actually attempted to logon there. Pwd policy is "empty" by default, i.e. nobody is in "allowed to reveal" list. It is admin's responsibility to populate this list. We might have some UI that helps with this process. Once the hash is sent down, there's no way to remove it from RODC, basically because we do not trust that RODC will remove it, even if instructed to do so. Therefore, the only way to "expire" the hash is to change the password. We store the list of passwords that were sent down to RODC in an attribute on the RODC computer object (the hub DC updates the list when it sends a pwd). So, if the RODC is stolen, you can enumerate whose passwords were down there, and make these users reset their passwords. There's a constructed attribute that returns only the users whose * current* passwords appear to be on the RODC. WRT what data is sent down “ currently, we send everything, sans a handful of "secret" attributes, which are controlled by pwd replication policy. There's a DCR to be able to configure the list of attributes that can go down to RODC (aka RODC PAS), but it is not yet clear if we will get it done or not. Note that the client data access story on RODC becomes quite convoluted because you don't know if you are seeing the whole object or only a subset of it. We do not normally issue referrals due to "partial reads". From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of neil.ruston@xxxxxxxxxxxxxSent: Friday, July 28, 2006 8:22 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core RODC stores password hashes only for a pre defined list of users and they are not stored on a permanent basis. [I'm unclear how the latter is achieved.] The goal is such that if the RODC were removed from the office then no password secrets could be extracted from that machine. neil From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent: 28 July 2006 16:08To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] Read-Only Domain Controller and Server Core The part that makes me wonder about the "story" is if it stores no secrets is the server doing anything for me? Is there a point to deploying the server in a remote office other than just being able to point to it in the closet and say, "see, I do to earn my paycheck!" I'm sure there's more, but I don't yet know which parts are public information and which are NDA. Can you tell I'm concerned about the story being created? I like stories; don't get me wrong. But I'm concerned that the story being spun up might be missing the mark and lead a few people astray. Safe to note that there are some features that differentiate the RODC from a NT4 BDC and that make it appealing in some cases. But if it actually does not store anything locally, ever, then I'm not sure it's worth the time to deploy one now is it? Al On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] sbradcpa@xxxxxxxxxxx> wrote: FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx Read-Only Domain Controller and Server CoreList info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email please notify the sender immediately and delete your copy from your system. You must not copy, distribute or take any further action in reliance on it. Email is not a secure method of communication and Nomura International plc ('NIplc') will not, to the extent permitted by law, accept responsibility or liability for (a) the accuracy or completeness of, or (b) the presence of any virus, worm or similar malicious or disabling code in, this message or any attachment(s) to it. If verification of this email is sought then please request a hard copy. Unless otherwise stated this email: (1) is not, and should not be treated or relied upon as, investment research; (2) contains views or opinions that are solely those of the author and do not necessarily represent those of NIplc; (3) is intended for informational purposes only and is not a recommendation, solicitation or offer to buy or sell securities or related financial instruments. NIplc does not provide investment services to private customers. Authorised and regulated by the Financial Services Authority. Registered in England no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand, London, EC1A 4NP. A member of the Nomura group of companies.

AD000001017 User is Offline

Posts:0

08/02/2006 8:41 AM
Yes subject lines like RODC catch attention, but most of us from the AD team read ActiveDir regularly. I™m still digesting the great feedback and comments on this thread, but one quick note about the Password Replication Policy: A new option to Repadmin is being built to help with the business logic of who is in each branch. As pointed out earlier there is a new attribute called msDS-AuthenticatedToAccountlist aka Auth2 on the RODC machine account which is updated by a writeable KDC whenever a client is given a session ticket to a RODC. This should help admins with a starting point for who to cache in the branch (if they don™t already have security groups for the branches). The tool can be run for ALL RODCs in the domain and will move computers\users from Auth2 to the Allow list if the accounts are not already denied (IE a DA could show up on Auth2 but since they are part of the default deny list they wouldn™t be moved). Yes we could have used OU™s, but we felt that not enough customers used OU™s based on physical branch sites to make that the primary means of defining the replication\caching policy. Feedback is welcome. For example, repadmin /prp move * would move the auth2 list to the allow list for every rodc, or repadmin /prp move Rodc-1 for a single rodc. Since the entire PRP scheme is comprised of LDAP attributes then it should be quite easy to script and also usable by provisioning tools. -Nathan Muggli RODC Program Manager From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe Sent: Monday, July 31, 2006 3:26 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core No, if you see Nathan in a McDonald's restaurant, please, ask for his autograph. That is fine, he will probably grin and laugh, he is a great guy. Anyway, he obviously isn't working if he is hanging out there so getting his autograph is fine. However, don't email him and take him away from his very important work because if he is in front of a computer to read your email, chances are, he is working. :) Mostly I just wanted to point out to the list denizens who maybe don't know names that we have some pretty heavy hitters lurking on this list so if they ever think it is a waste to post what they think is wrong with AD or the Domain Environment or ADAM or what not, they shouldn't think that. This is one of the best places to post it because actual Developers/PMs like Dmitri/Nathan, people who care greatly but aren't directly on the Dev team like ~Eric and Brian, and general purpose rock stars like Stuart Kwan of the Ottawa Kwan Clan are reading this list. I expect they are mostly avoiding my rants but they do watch for certain topics. Something like RODC and Server Core certainly will catch their attention at the moment obviously. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura A. Robinson Sent: Monday, July 31, 2006 4:30 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Joe, isn't the below kind of like yelling, "OMG! Elvis!" in a McDonald's restaurant in Kalamazoo and following it up with, "nobody ask for his autograph"? ;-) Laura From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe Sent: Monday, July 31, 2006 3:13 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Whoa... Nathan too. This list is hopping... For those folks who don't know Nathan... Read his signature carefully and realize the level of people this list is seen by. And don't email him directly unless you found a world ending issue with Longhorn DCs, he is a busy guy about right now. :) I could easily bother Nathan with about 40 emails a day but try to leave him completely alone. All I say is if this stuff is implemented, please please please please have the details in the Platform SDK ASAP. Actualy flag values and meanings and caveates and everything else. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Nathan Muggli Sent: Monday, July 31, 2006 12:18 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core We thought about using the confidential flag as the denotation for the RO-PAS, but that would break too many applications. The RO-PAS would only be for applications that wanted to protect their secrets from replicating to a RODC. DIMS (aka cred roaming) is a prime example. Most likely if RO-PAS happens it will be a negative PAS in that the marking in the schema would mean that the attr is NOT replicated. That way new vanilla attributes are replicated to a RODC which would minimize app compat. -Nathan Muggli RODC Program Manager From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido Sent: Monday, July 31, 2006 1:35 AM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Not sure if it makes sense, but this could potentially be combined with the confidential flag “ RODCs wouldn™t cache any confidential attributes, unless a Confidential Data Caching Policy would allow them to do so¦ The confidential flag is already used by the Digital Identity Management Service (DIMS) for the Credential Roaming feature. And instead of adding yet another flag to differentiate attributes which contain secrets or sensitive data, this may just be the right flag. Granted, none of this will make life easier for app developers. /Guido From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brian Puhl Sent: Monday, July 31, 2006 10:05 AM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core You™re right Joe “ that the RODC PAS would complicate things for the developers. The easy solution would be for developers to use the writeable flag when connecting to a DC, then they™d be guaranteed to not get an RODC¦but even that isn™t a great solution, and if we get the RODC GC it only becomes more complex. For general background though, the justification for the RODC PAS DCR is actually that there are numerous attributes which contain password hash, or password-like data. Because these attributes aren™t part of the pre-defined list of secrets, they are replicated normally rather than on-demand via the PRP. It wouldn™t do me much good to prevent replication of 5 password attributes, when a 6th one which also includes a hash gets pushed down through normal replication. There needs to be a way for an administrator to define where these secrets live and protect them accordingly. I™ve broached the topic of using this method to protect PII data a couple of times in relation to some RODC work we™re doing internally, and the response is always that it™s firmly in the realm of unsupported followed with a that™d be a bad idea and some serious head shaking “ simply because of the way applications behave. Brian From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe Sent: Sunday, July 30, 2006 5:08 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core I am not sure if I understand where you are going but let me explain where I am coming from. First, the passwords being there or not being there is not important for this talk, that is already built in and will be there, now the discussion is around everything versus an RODC PAS. Everything is already there as well but is an important option because it will be the most used option. Actually I expect to see a ton of RODCs deployed that are configured as replicate everything including passwords so that people get the RO part of the benefit and they don't have to worry about replicating bad stuff back into the "real directory" and not have to worry about password caching management, if someone logs on somewhere, the password is cached there, bob's your uncle have a nice day. So now we get down to replicating a portion of the normal attribute set. Why would you want to do this? Because you want to minimize the traffic to WAN sites and/or reduced info in some locations in case of compromise. For instance, if the email addresses of everyone in the company isn't on a DC in a WAN site and someone steals that DC hoping to get those email addresses, they are SOL; they missed. However, now think about this from a application developer standpoint and it is the same issue that exists with GCs only worse because it is DCs. If an app developer wants to find something, they need to understand what they can actually find in the GC in terms of what attributes are populated. Maybe they (a) put in a requirement and hope people follow it, maybe they (b) actually try to verify it, maybe they (c) say screw that and query a DC instead because they know all of the data is there for a full query. >From what I have seen the likely cases for an app that can handle any query is C, A, and in the absolute blue moon case B. Usually the app will just fail to find what it needs if you specify an attribute that isn't in the GC. How does Exchange do it??? So there are hybrids like where certain things that people KNOW will always be in GC PAS and they will set it up so that queries using those things will use a GC and everything else will go to a DC. We already know that the same override that exists for the GC PAS would have to exist for an RODC PAS so why not just make that the other option and be done with it? I don't really see the majority of developers doing this any better with RODCs than they do with GCs and so it seems like a lot of make work to allow for the flexible handling of that if you just say these are the options. Again also the password thing isn't even worried about at the app level since apps can play with those anyway. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick Sent: Sunday, July 30, 2006 6:57 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core Um, why? What value at this point? Last I checked it supports limited applications that might want that information. And if you follow ~Eric's logic, they want to be secure out of the box. That would indicate that they want it to be as minimal as possible until and unless told otherwise. To put that information in there by default might be counter to that. Now, if you had some templates or something so that we didn't have to work on the carpal tunnel, that would be something....:) On 7/30/06, joe wrote: RE: RODC PAS.... Oi, that will add some nice complexity to all of this... :) If I was looking to implement that I think I would look at doing it in four levels so people don't shoot themselves... Everything, everything but password info, core NOS info required for auth/authz with passwords, core NOS w/o passwords. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dmitri Gavrilov Sent: Friday, July 28, 2006 12:48 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core The set of passwords that can be sent down to the RODC is controlled by password replication policy. The passwords are sent down by RODC's request, but the hub also checks whether the user (whose pwd is being requested) actually attempted to authenticate at RODC (the hub can induce this info from the traffic is sees). The pwd hash is sent down only if both are satisfied: pwd policy allows it and the user actually attempted to logon there. Pwd policy is "empty" by default, i.e. nobody is in "allowed to reveal" list. It is admin's responsibility to populate this list. We might have some UI that helps with this process. Once the hash is sent down, there's no way to remove it from RODC, basically because we do not trust that RODC will remove it, even if instructed to do so. Therefore, the only way to "expire" the hash is to change the password. We store the list of passwords that were sent down to RODC in an attribute on the RODC computer object (the hub DC updates the list when it sends a pwd). So, if the RODC is stolen, you can enumerate whose passwords were down there, and make these users reset their passwords. There's a constructed attribute that returns only the users whose * current* passwords appear to be on the RODC. WRT what data is sent down “ currently, we send everything, sans a handful of "secret" attributes, which are controlled by pwd replication policy. There's a DCR to be able to configure the list of attributes that can go down to RODC (aka RODC PAS), but it is not yet clear if we will get it done or not. Note that the client data access story on RODC becomes quite convoluted because you don't know if you are seeing the whole object or only a subset of it. We do not normally issue referrals due to "partial reads". From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of neil.ruston@xxxxxxxxxxxxx Sent: Friday, July 28, 2006 8:22 AM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core RODC stores password hashes only for a pre defined list of users and they are not stored on a permanent basis. [I'm unclear how the latter is achieved.] The goal is such that if the RODC were removed from the office then no password secrets could be extracted from that machine. neil From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick Sent: 28 July 2006 16:08 To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core The part that makes me wonder about the "story" is if it stores no secrets is the server doing anything for me? Is there a point to deploying the server in a remote office other than just being able to point to it in the closet and say, "see, I do to earn my paycheck!" I'm sure there's more, but I don't yet know which parts are public information and which are NDA. Can you tell I'm concerned about the story being created? I like stories; don't get me wrong. But I'm concerned that the story being spun up might be missing the mark and lead a few people astray. Safe to note that there are some features that differentiate the RODC from a NT4 BDC and that make it appealing in some cases. But if it actually does not store anything locally, ever, then I'm not sure it's worth the time to deploy one now is it? Al On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: FYI: http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx Read-Only Domain Controller and Server Core 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 PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email please notify the sender immediately and delete your copy from your system. You must not copy, distribute or take any further action in reliance on it. Email is not a secure method of communication and Nomura International plc ('NIplc') will not, to the extent permitted by law, accept responsibility or liability for (a) the accuracy or completeness of, or (b) the presence of any virus, worm or similar malicious or disabling code in, this message or any attachment(s) to it. If verification of this email is sought then please request a hard copy. Unless otherwise stated this email: (1) is not, and should not be treated or relied upon as, investment research; (2) contains views or opinions that are solely those of the author and do not necessarily represent those of NIplc; (3) is intended for informational purposes only and is not a recommendation, solicitation or offer to buy or sell securities or related financial instruments. NIplc does not provide investment services to private customers. Authorised and regulated by the Financial Services Authority. Registered in England no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand, London, EC1A 4NP. A member of the Nomura group of companies.

AD000001017 User is Offline

Posts:0

GuidoG

Posts:114

08/03/2006 10:38 AM
Great information Nathan “ thanks! Certainly good to know how the msDS-AuthenticatedToAccountlist attribute is updated. What does PRP stand for? And is it correct to say that the PRP move feature in repadmin would directly populate the Password caching Policy of the RODC servers with each security principal (users, computers) that have authenticated to the RODC (as opposed to using some RODC specific security group)? Which means that all of these account references would be stored in the msDS-RevealOnDemandGroup attribute¦ Hmm, while thinking about this, I wondered if this is only appropriate for smaller or even for larger environments. I was thinking about possible limitation regarding how many entries could exist in the msDS-RevealOnDemandGroup multivalue attribute and if they™d be replicated as a blob “ but from checking the schema, this is a linked attribute so I assume it also supports LVR (assuming at least FFL2; which I don™t think is a requirement for RODC). Thus “ once FFL2 is reached “ there should be no limit as to the number of accounts to populate that attribute with. So basically “ if my assumptions regarding LVR capabilities of this attribute are correct, the msDS-RevealOnDemandGroup could be seen as the most appropriate attribute to populate the accounts directly, unless I really want to use or already have a security group. This way, I don™t have to add another group to any users™ token. This would be cool “ even without repadmin™s PRP move feature, we could auto-populate the msDS-RevealOnDemandGroup attributes of the respective RODCs based on other queries, such as office etc. or a combination of the results including the Auth2 entries. The only downside would maybe be that there is no back-link to the objects, so I couldn™t check a user account and see which RODC allows to cache its password (I know I can check the msDS-RevealedDSAs attribute to see where a user pwd has been cached). This looks very promising! /Guido From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Nathan Muggli Sent: Wednesday, August 02, 2006 10:41 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Yes subject lines like RODC catch attention, but most of us from the AD team read ActiveDir regularly. I™m still digesting the great feedback and comments on this thread, but one quick note about the Password Replication Policy: A new option to Repadmin is being built to help with the business logic of who is in each branch. As pointed out earlier there is a new attribute called msDS-AuthenticatedToAccountlist aka Auth2 on the RODC machine account which is updated by a writeable KDC whenever a client is given a session ticket to a RODC. This should help admins with a starting point for who to cache in the branch (if they don™t already have security groups for the branches). The tool can be run for ALL RODCs in the domain and will move computers\users from Auth2 to the Allow list if the accounts are not already denied (IE a DA could show up on Auth2 but since they are part of the default deny list they wouldn™t be moved). Yes we could have used OU™s, but we felt that not enough customers used OU™s based on physical branch sites to make that the primary means of defining the replication\caching policy. Feedback is welcome. For example, repadmin /prp move * would move the auth2 list to the allow list for every rodc, or repadmin /prp move Rodc-1 for a single rodc. Since the entire PRP scheme is comprised of LDAP attributes then it should be quite easy to script and also usable by provisioning tools. -Nathan Muggli RODC Program Manager From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe Sent: Monday, July 31, 2006 3:26 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core No, if you see Nathan in a McDonald's restaurant, please, ask for his autograph. That is fine, he will probably grin and laugh, he is a great guy. Anyway, he obviously isn't working if he is hanging out there so getting his autograph is fine. However, don't email him and take him away from his very important work because if he is in front of a computer to read your email, chances are, he is working. :) Mostly I just wanted to point out to the list denizens who maybe don't know names that we have some pretty heavy hitters lurking on this list so if they ever think it is a waste to post what they think is wrong with AD or the Domain Environment or ADAM or what not, they shouldn't think that. This is one of the best places to post it because actual Developers/PMs like Dmitri/Nathan, people who care greatly but aren't directly on the Dev team like ~Eric and Brian, and general purpose rock stars like Stuart Kwan of the Ottawa Kwan Clan are reading this list. I expect they are mostly avoiding my rants but they do watch for certain topics. Something like RODC and Server Core certainly will catch their attention at the moment obviously. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura A. Robinson Sent: Monday, July 31, 2006 4:30 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Joe, isn't the below kind of like yelling, "OMG! Elvis!" in a McDonald's restaurant in Kalamazoo and following it up with, "nobody ask for his autograph"? ;-) Laura From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe Sent: Monday, July 31, 2006 3:13 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Whoa... Nathan too. This list is hopping... For those folks who don't know Nathan... Read his signature carefully and realize the level of people this list is seen by. And don't email him directly unless you found a world ending issue with Longhorn DCs, he is a busy guy about right now. :) I could easily bother Nathan with about 40 emails a day but try to leave him completely alone. All I say is if this stuff is implemented, please please please please have the details in the Platform SDK ASAP. Actualy flag values and meanings and caveates and everything else. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Nathan Muggli Sent: Monday, July 31, 2006 12:18 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core We thought about using the confidential flag as the denotation for the RO-PAS, but that would break too many applications. The RO-PAS would only be for applications that wanted to protect their secrets from replicating to a RODC. DIMS (aka cred roaming) is a prime example. Most likely if RO-PAS happens it will be a negative PAS in that the marking in the schema would mean that the attr is NOT replicated. That way new vanilla attributes are replicated to a RODC which would minimize app compat. -Nathan Muggli RODC Program Manager From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido Sent: Monday, July 31, 2006 1:35 AM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Not sure if it makes sense, but this could potentially be combined with the confidential flag “ RODCs wouldn™t cache any confidential attributes, unless a Confidential Data Caching Policy would allow them to do so¦ The confidential flag is already used by the Digital Identity Management Service (DIMS) for the Credential Roaming feature. And instead of adding yet another flag to differentiate attributes which contain secrets or sensitive data, this may just be the right flag. Granted, none of this will make life easier for app developers. /Guido From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brian Puhl Sent: Monday, July 31, 2006 10:05 AM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core You™re right Joe “ that the RODC PAS would complicate things for the developers. The easy solution would be for developers to use the writeable flag when connecting to a DC, then they™d be guaranteed to not get an RODC¦but even that isn™t a great solution, and if we get the RODC GC it only becomes more complex. For general background though, the justification for the RODC PAS DCR is actually that there are numerous attributes which contain password hash, or password-like data. Because these attributes aren™t part of the pre-defined list of secrets, they are replicated normally rather than on-demand via the PRP. It wouldn™t do me much good to prevent replication of 5 password attributes, when a 6th one which also includes a hash gets pushed down through normal replication. There needs to be a way for an administrator to define where these secrets live and protect them accordingly. I™ve broached the topic of using this method to protect PII data a couple of times in relation to some RODC work we™re doing internally, and the response is always that it™s firmly in the realm of unsupported followed with a that™d be a bad idea and some serious head shaking “ simply because of the way applications behave. Brian From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe Sent: Sunday, July 30, 2006 5:08 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core I am not sure if I understand where you are going but let me explain where I am coming from. First, the passwords being there or not being there is not important for this talk, that is already built in and will be there, now the discussion is around everything versus an RODC PAS. Everything is already there as well but is an important option because it will be the most used option. Actually I expect to see a ton of RODCs deployed that are configured as replicate everything including passwords so that people get the RO part of the benefit and they don't have to worry about replicating bad stuff back into the "real directory" and not have to worry about password caching management, if someone logs on somewhere, the password is cached there, bob's your uncle have a nice day. So now we get down to replicating a portion of the normal attribute set. Why would you want to do this? Because you want to minimize the traffic to WAN sites and/or reduced info in some locations in case of compromise. For instance, if the email addresses of everyone in the company isn't on a DC in a WAN site and someone steals that DC hoping to get those email addresses, they are SOL; they missed. However, now think about this from a application developer standpoint and it is the same issue that exists with GCs only worse because it is DCs. If an app developer wants to find something, they need to understand what they can actually find in the GC in terms of what attributes are populated. Maybe they (a) put in a requirement and hope people follow it, maybe they (b) actually try to verify it, maybe they (c) say screw that and query a DC instead because they know all of the data is there for a full query. >From what I have seen the likely cases for an app that can handle any query is C, A, and in the absolute blue moon case B. Usually the app will just fail to find what it needs if you specify an attribute that isn't in the GC. How does Exchange do it??? So there are hybrids like where certain things that people KNOW will always be in GC PAS and they will set it up so that queries using those things will use a GC and everything else will go to a DC. We already know that the same override that exists for the GC PAS would have to exist for an RODC PAS so why not just make that the other option and be done with it? I don't really see the majority of developers doing this any better with RODCs than they do with GCs and so it seems like a lot of make work to allow for the flexible handling of that if you just say these are the options. Again also the password thing isn't even worried about at the app level since apps can play with those anyway. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick Sent: Sunday, July 30, 2006 6:57 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core Um, why? What value at this point? Last I checked it supports limited applications that might want that information. And if you follow ~Eric's logic, they want to be secure out of the box. That would indicate that they want it to be as minimal as possible until and unless told otherwise. To put that information in there by default might be counter to that. Now, if you had some templates or something so that we didn't have to work on the carpal tunnel, that would be something....:) On 7/30/06, joe listmail@xxxxxxxxxxx> wrote: RE: RODC PAS.... Oi, that will add some nice complexity to all of this... :) If I was looking to implement that I think I would look at doing it in four levels so people don't shoot themselves... Everything, everything but password info, core NOS info required for auth/authz with passwords, core NOS w/o passwords. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dmitri Gavrilov Sent: Friday, July 28, 2006 12:48 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core The set of passwords that can be sent down to the RODC is controlled by password replication policy. The passwords are sent down by RODC's request, but the hub also checks whether the user (whose pwd is being requested) actually attempted to authenticate at RODC (the hub can induce this info from the traffic is sees). The pwd hash is sent down only if both are satisfied: pwd policy allows it and the user actually attempted to logon there. Pwd policy is "empty" by default, i.e. nobody is in "allowed to reveal" list. It is admin's responsibility to populate this list. We might have some UI that helps with this process. Once the hash is sent down, there's no way to remove it from RODC, basically because we do not trust that RODC will remove it, even if instructed to do so. Therefore, the only way to "expire" the hash is to change the password. We store the list of passwords that were sent down to RODC in an attribute on the RODC computer object (the hub DC updates the list when it sends a pwd). So, if the RODC is stolen, you can enumerate whose passwords were down there, and make these users reset their passwords. There's a constructed attribute that returns only the users whose * current* passwords appear to be on the RODC. WRT what data is sent down “ currently, we send everything, sans a handful of "secret" attributes, which are controlled by pwd replication policy. There's a DCR to be able to configure the list of attributes that can go down to RODC (aka RODC PAS), but it is not yet clear if we will get it done or not. Note that the client data access story on RODC becomes quite convoluted because you don't know if you are seeing the whole object or only a subset of it. We do not normally issue referrals due to "partial reads". From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of neil.ruston@xxxxxxxxxxxxx Sent: Friday, July 28, 2006 8:22 AM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core RODC stores password hashes only for a pre defined list of users and they are not stored on a permanent basis. [I'm unclear how the latter is achieved.] The goal is such that if the RODC were removed from the office then no password secrets could be extracted from that machine. neil From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick Sent: 28 July 2006 16:08 To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core The part that makes me wonder about the "story" is if it stores no secrets is the server doing anything for me? Is there a point to deploying the server in a remote office other than just being able to point to it in the closet and say, "see, I do to earn my paycheck!" I'm sure there's more, but I don't yet know which parts are public information and which are NDA. Can you tell I'm concerned about the story being created? I like stories; don't get me wrong. But I'm concerned that the story being spun up might be missing the mark and lead a few people astray. Safe to note that there are some features that differentiate the RODC from a NT4 BDC and that make it appealing in some cases. But if it actually does not store anything locally, ever, then I'm not sure it's worth the time to deploy one now is it? Al On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] sbradcpa@xxxxxxxxxxx> wrote: FYI: http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx Read-Only Domain Controller and Server Core 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 PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email please notify the sender immediately and delete your copy from your system. You must not copy, distribute or take any further action in reliance on it. Email is not a secure method of communication and Nomura International plc ('NIplc') will not, to the extent permitted by law, accept responsibility or liability for (a) the accuracy or completeness of, or (b) the presence of any virus, worm or similar malicious or disabling code in, this message or any attachment(s) to it. If verification of this email is sought then please request a hard copy. Unless otherwise stated this email: (1) is not, and should not be treated or relied upon as, investment research; (2) contains views or opinions that are solely those of the author and do not necessarily represent those of NIplc; (3) is intended for informational purposes only and is not a recommendation, solicitation or offer to buy or sell securities or related financial instruments. NIplc does not provide investment services to private customers. Authorised and regulated by the Financial Services Authority. Registered in England no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand, London, EC1A 4NP. A member of the Nomura group of companies.

efleis1

Posts:0

08/28/2006 3:31 AM
To be clear as your comments don™t seem to indicate the why as much as Nathan™s did, we were less interested in the bandwidth savings and more interested in the accuracy of the list. Non-LVR link values have a value loss potential on conflicted write across DCs. ~Eric From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido Sent: Monday, August 28, 2006 5:40 AM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core > RODCs require Win2k03 FFM. This is so that we can guarantee a higher degree > of accuracy for the password reveal list (msDS-RevealedUsers and the constructed > version msDS-RevealedList) due to LVR Been thinking more about the requirement for the Windows Server 2003 Forest Functional Level (FFL2) to deploy RODCs¦ It certainly makes sense to leverage LVR (linked value replication) to reduce the amount of data being replicated around and to eliminate the 5000 values replication limit due to the limit of the jet-db version store. Just wondering how many companies are still running a pure Win2000 AD forest and want to upgrade directly to Longhorn (skipping deployment of Windows Server 2003 DCs)? Do they realize that they will not be able to deploy RODCs prior to first upgrading or replacing ALL Win2000 DCs in the forest with writeable Longhorn DCs? They will then be able to switch to FFL3 (Longhorn Server) and in a second phase of the upgrade project they can take care of deploying RODCs. And since you can™t just switch the mode of a writeable DC to an RODC (and vice versa), this usually means to de-promote the writeable LH DCs and then to re-promote them as RODCs (where you want them “ for example you™ll still want writeable DCs in your hub sites). Naturally this de-promo and re-promo process can be scripted, but it™s still an extra phase in the project that takes time and efforts and must be planned appropriately. Companies who have already upgraded to Win2003 and are running at Win2003 FFL will have less of an issue “ they will be able to deploy RODCs right into their existing Win2003 forests. The PDC of the respective domain must run Longhorn, but that™s a small price to pay. So, it would be good to get some feedback from this list, A. how many of you are planning to upgrade your AD directly from Win2000 to Longhorn Server? B. how many are planning to upgrade from Windows2003 FFL? C. how many think they are still in-between (have Win2003 AD, but couldn™t yet reach Win2003 FFL for some reason, such as some Win2000 or WinNT DCs still hanging around)? Thanks, Guido From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Nathan Muggli Sent: Thursday, August 03, 2006 8:52 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core PRP = Password Replication Policy Yes the tool will directly populate the Allow or Deny attributes (msDS-RevealOnDemandGroup and msDS-NeverRevealGroup respectively) with the security principal. Ideally the users\computers would be put into a group, and then the group added to the Allow list. That way you only have to manipulate the group and not the attributes. The tool will most likely support a generic add operation to add a group (or user\comptuer) to the Allow\Deny list and then you could use whatever group manipulation tool you wanted. RODCs require Win2k03 FFM. This is so that we can guarantee a higher degree of accuracy for the password reveal list (msDS-RevealedUsers and the constructed version msDS-RevealedList) due to LVR. Interesting suggestion on the BL for msDS-RevealOnDemandGroup\msDS-NeverRevealGroup. The only issue I see with that is if groups are used instead of individual users\computers. I don™t think it™s as useful to see a BL on a group since you really want to see the user. However, that said, we are providing a new RootDSE operation called verify cacheability that will return three values (allowed, explicitly denied, and not on deny or allow). Its input will be a security principal and a rodc, so while PRP knowledge won™t be stored on the user\computer you can easily check a given user to see if they are cacheable at a given RODC. There are two new links on the user\computer objects related to RODCs. One is msDS-AuthenticatedAtDC (which is actually the FL to msDS-AuthenticatedToAccountlist for performance reasons). The other as you pointed out is msDS-RevealedDSAs which shows which RODCs the user\computer has been cached at. Since the PRP is per RODC, we do stamp a common group for both allow and deny by default on every RODC promotion to aid in one-to-many management (ie for service accounts, etc). The new groups (which are created when the PDC is upgraded to LH) are Domain RODC Password Replication Allowed Group and Domain RODC Password Replication Denied Group. So the current default PRP on RODC promotion looks like this: msDS-RevealOnDemandGroup: CN=Domain RODC Password Replication Allowed Group,CN=Users,DC=X msDS-NeverRevealGroup: CN=Domain RODC Password Replication Denied Group,CN=Users,DC=X CN=Account Operators,CN=Builtin,DC=X CN=Server Operators,CN=Builtin,DC=X CN=Backup Operators,CN=Builtin,DC=X CN=Administrators,CN=Builtin,DC=X The common allow group is empty by default. The common deny group contains the following members: CN=Enterprise Read-only Domain Controllers,CN=WellKnown Security Principals,CN=Configuration,DC=X CN=Group Policy Creator Owners,CN=Users,DC=X; CN=Domain Admins,CN=Users,DC=rX CN=Cert Publishers,CN=Users,DC=X CN=Enterprise Admins,CN=Users,DC=X CN=Schema Admins,CN=Users,DC=X CN=krbtgt,CN=Users,DC=X -Nathan Muggli RODC Program Manager From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido Sent: Thursday, August 03, 2006 3:38 AM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Great information Nathan “ thanks! Certainly good to know how the msDS-AuthenticatedToAccountlist attribute is updated. What does PRP stand for? And is it correct to say that the PRP move feature in repadmin would directly populate the Password caching Policy of the RODC servers with each security principal (users, computers) that have authenticated to the RODC (as opposed to using some RODC specific security group)? Which means that all of these account references would be stored in the msDS-RevealOnDemandGroup attribute¦ Hmm, while thinking about this, I wondered if this is only appropriate for smaller or even for larger environments. I was thinking about possible limitation regarding how many entries could exist in the msDS-RevealOnDemandGroup multivalue attribute and if they™d be replicated as a blob “ but from checking the schema, this is a linked attribute so I assume it also supports LVR (assuming at least FFL2; which I don™t think is a requirement for RODC). Thus “ once FFL2 is reached “ there should be no limit as to the number of accounts to populate that attribute with. So basically “ if my assumptions regarding LVR capabilities of this attribute are correct, the msDS-RevealOnDemandGroup could be seen as the most appropriate attribute to populate the accounts directly, unless I really want to use or already have a security group. This way, I don™t have to add another group to any users™ token. This would be cool “ even without repadmin™s PRP move feature, we could auto-populate the msDS-RevealOnDemandGroup attributes of the respective RODCs based on other queries, such as office etc. or a combination of the results including the Auth2 entries. The only downside would maybe be that there is no back-link to the objects, so I couldn™t check a user account and see which RODC allows to cache its password (I know I can check the msDS-RevealedDSAs attribute to see where a user pwd has been cached). This looks very promising! /Guido

GuidoG

Posts:114

08/28/2006 12:40 PM
> RODCs require Win2k03 FFM. This is so that we can guarantee a higher degree > of accuracy for the password reveal list (msDS-RevealedUsers and the constructed > version msDS-RevealedList) due to LVR Been thinking more about the requirement for the Windows Server 2003 Forest Functional Level (FFL2) to deploy RODCs¦ It certainly makes sense to leverage LVR (linked value replication) to reduce the amount of data being replicated around and to eliminate the 5000 values replication limit due to the limit of the jet-db version store. Just wondering how many companies are still running a pure Win2000 AD forest and want to upgrade directly to Longhorn (skipping deployment of Windows Server 2003 DCs)? Do they realize that they will not be able to deploy RODCs prior to first upgrading or replacing ALL Win2000 DCs in the forest with writeable Longhorn DCs? They will then be able to switch to FFL3 (Longhorn Server) and in a second phase of the upgrade project they can take care of deploying RODCs. And since you can™t just switch the mode of a writeable DC to an RODC (and vice versa), this usually means to de-promote the writeable LH DCs and then to re-promote them as RODCs (where you want them “ for example you™ll still want writeable DCs in your hub sites). Naturally this de-promo and re-promo process can be scripted, but it™s still an extra phase in the project that takes time and efforts and must be planned appropriately. Companies who have already upgraded to Win2003 and are running at Win2003 FFL will have less of an issue “ they will be able to deploy RODCs right into their existing Win2003 forests. The PDC of the respective domain must run Longhorn, but that™s a small price to pay. So, it would be good to get some feedback from this list, A. how many of you are planning to upgrade your AD directly from Win2000 to Longhorn Server? B. how many are planning to upgrade from Windows2003 FFL? C. how many think they are still in-between (have Win2003 AD, but couldn™t yet reach Win2003 FFL for some reason, such as some Win2000 or WinNT DCs still hanging around)? Thanks, Guido From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Nathan Muggli Sent: Thursday, August 03, 2006 8:52 PM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core PRP = Password Replication Policy Yes the tool will directly populate the Allow or Deny attributes (msDS-RevealOnDemandGroup and msDS-NeverRevealGroup respectively) with the security principal. Ideally the users\computers would be put into a group, and then the group added to the Allow list. That way you only have to manipulate the group and not the attributes. The tool will most likely support a generic add operation to add a group (or user\comptuer) to the Allow\Deny list and then you could use whatever group manipulation tool you wanted. RODCs require Win2k03 FFM. This is so that we can guarantee a higher degree of accuracy for the password reveal list (msDS-RevealedUsers and the constructed version msDS-RevealedList) due to LVR. Interesting suggestion on the BL for msDS-RevealOnDemandGroup\msDS-NeverRevealGroup. The only issue I see with that is if groups are used instead of individual users\computers. I don™t think it™s as useful to see a BL on a group since you really want to see the user. However, that said, we are providing a new RootDSE operation called verify cacheability that will return three values (allowed, explicitly denied, and not on deny or allow). Its input will be a security principal and a rodc, so while PRP knowledge won™t be stored on the user\computer you can easily check a given user to see if they are cacheable at a given RODC. There are two new links on the user\computer objects related to RODCs. One is msDS-AuthenticatedAtDC (which is actually the FL to msDS-AuthenticatedToAccountlist for performance reasons). The other as you pointed out is msDS-RevealedDSAs which shows which RODCs the user\computer has been cached at. Since the PRP is per RODC, we do stamp a common group for both allow and deny by default on every RODC promotion to aid in one-to-many management (ie for service accounts, etc). The new groups (which are created when the PDC is upgraded to LH) are Domain RODC Password Replication Allowed Group and Domain RODC Password Replication Denied Group. So the current default PRP on RODC promotion looks like this: msDS-RevealOnDemandGroup: CN=Domain RODC Password Replication Allowed Group,CN=Users,DC=X msDS-NeverRevealGroup: CN=Domain RODC Password Replication Denied Group,CN=Users,DC=X CN=Account Operators,CN=Builtin,DC=X CN=Server Operators,CN=Builtin,DC=X CN=Backup Operators,CN=Builtin,DC=X CN=Administrators,CN=Builtin,DC=X The common allow group is empty by default. The common deny group contains the following members: CN=Enterprise Read-only Domain Controllers,CN=WellKnown Security Principals,CN=Configuration,DC=X CN=Group Policy Creator Owners,CN=Users,DC=X; CN=Domain Admins,CN=Users,DC=rX CN=Cert Publishers,CN=Users,DC=X CN=Enterprise Admins,CN=Users,DC=X CN=Schema Admins,CN=Users,DC=X CN=krbtgt,CN=Users,DC=X -Nathan Muggli RODC Program Manager From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido Sent: Thursday, August 03, 2006 3:38 AM To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Great information Nathan “ thanks! Certainly good to know how the msDS-AuthenticatedToAccountlist attribute is updated. What does PRP stand for? And is it correct to say that the PRP move feature in repadmin would directly populate the Password caching Policy of the RODC servers with each security principal (users, computers) that have authenticated to the RODC (as opposed to using some RODC specific security group)? Which means that all of these account references would be stored in the msDS-RevealOnDemandGroup attribute¦ Hmm, while thinking about this, I wondered if this is only appropriate for smaller or even for larger environments. I was thinking about possible limitation regarding how many entries could exist in the msDS-RevealOnDemandGroup multivalue attribute and if they™d be replicated as a blob “ but from checking the schema, this is a linked attribute so I assume it also supports LVR (assuming at least FFL2; which I don™t think is a requirement for RODC). Thus “ once FFL2 is reached “ there should be no limit as to the number of accounts to populate that attribute with. So basically “ if my assumptions regarding LVR capabilities of this attribute are correct, the msDS-RevealOnDemandGroup could be seen as the most appropriate attribute to populate the accounts directly, unless I really want to use or already have a security group. This way, I don™t have to add another group to any users™ token. This would be cool “ even without repadmin™s PRP move feature, we could auto-populate the msDS-RevealOnDemandGroup attributes of the respective RODCs based on other queries, such as office etc. or a combination of the results including the Auth2 entries. The only downside would maybe be that there is no back-link to the objects, so I couldn™t check a user account and see which RODC allows to cache its password (I know I can check the msDS-RevealedDSAs attribute to see where a user pwd has been cached). This looks very promising! /Guido

You are not authorized to post a reply.

Page 4 of 4

Forums >ActiveDir Mail List Archive >List Archives > [ActiveDir] Read-Only Domain Controller and Server Core

ActiveForums 3.7

Syndicate

Friends

List Archives

List Archives

Friends

Members

Articles

Related Links

Ads