[ActiveDir] DC Can't Handle DNS Pointed to Self
Hello: This is sort of a follow up to two recent postings. Any thoughts are welcome as I have now been trying to figure this one out for about a week. I have DC running as a virtual machine under (host W2k3 SP1 w/ VS 2005 R2; guest: W2k3 ENT R2). This machine was recently promoted. When its local DNS points to itself, the machine does not logon to the domain. It appears to not even know about itself. No one can get to it because it loads the non-domain firewall GPO (enabling the full firewall). When I point DNS across the WAN, it loads though interestingly it does not become visible on the network until I log into it (via the VS management tools). I can then log out and it stays visible. It then appears to function correctly. Any thoughts greatly appreciated. -- nme -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/399 - Release Date: 7/25/2006
RE: [ActiveDir] DC Can't Handle DNS Pointed to Self
Sounds like its not replicating. When you say non-domain firewall, what do you mean? You dont want any firewall on it unless you have a specific need. If you strip the firewall off, where does that leave you? If you use dcdiag and netdiag they should also give you an idea about whats going on. If you like, feel free to mail them to me. Cheers, Rob Robert Rutherford QuoStar Solutions Limited The Enterprise Pavilion Fern Barrow Wallisdown Poole Dorset BH12 5HH T: +44 (0) 8456 440 331 F: +44 (0) 8456 440 332 M: +44 (0) 7974 249 494 E: [EMAIL PROTECTED] W: www.quostar.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Noah Eiger Sent: 28 July 2006 07:20 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] DC Can't Handle DNS Pointed to Self Hello: This is sort of a follow up to two recent postings. Any thoughts are welcome as I have now been trying to figure this one out for about a week. I have DC running as a virtual machine under (host W2k3 SP1 w/ VS 2005 R2; guest: W2k3 ENT R2). This machine was recently promoted. When its local DNS points to itself, the machine does not logon to the domain. It appears to not even know about itself. No one can get to it because it loads the non-domain firewall GPO (enabling the full firewall). When I point DNS across the WAN, it loads though interestingly it does not become visible on the network until I log into it (via the VS management tools). I can then log out and it stays visible. It then appears to function correctly. Any thoughts greatly appreciated. -- nme -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/399 - Release Date: 7/25/2006
RE: [ActiveDir] DC Can't Handle DNS Pointed to Self
Also, whats your DNS setup? Robert Rutherford QuoStar Solutions Limited The Enterprise Pavilion Fern Barrow Wallisdown Poole Dorset BH12 5HH T: +44 (0) 8456 440 331 F: +44 (0) 8456 440 332 M: +44 (0) 7974 249 494 E: [EMAIL PROTECTED] W: www.quostar.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Noah Eiger Sent: 28 July 2006 07:20 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] DC Can't Handle DNS Pointed to Self Hello: This is sort of a follow up to two recent postings. Any thoughts are welcome as I have now been trying to figure this one out for about a week. I have DC running as a virtual machine under (host W2k3 SP1 w/ VS 2005 R2; guest: W2k3 ENT R2). This machine was recently promoted. When its local DNS points to itself, the machine does not logon to the domain. It appears to not even know about itself. No one can get to it because it loads the non-domain firewall GPO (enabling the full firewall). When I point DNS across the WAN, it loads though interestingly it does not become visible on the network until I log into it (via the VS management tools). I can then log out and it stays visible. It then appears to function correctly. Any thoughts greatly appreciated. -- nme -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/399 - Release Date: 7/25/2006
RE: [ActiveDir] R2 vs w2k3 SP1
Title: R2 vs w2k3 SP1 As an interesting aside, We noticed recently that using an R2 corporate license key on a 2K3 enterprise (integrated sp1) CD causes the media to request the 2nd disk even though there is no second disk in the media kit.. (blame the reseller, who supplied us with the incorrect key) Ive not had the opportunity (or enthusiasm) to test whether this is also the case with the standard edition __ Mike Guest| Capgemini | Sale Server Support | Outsourcing UK Office: + 44 (0)870 366 1814 | 700 1814| [EMAIL PROTECTED] 77-79 Cross Street, Sale, Cheshire. M33 7HG Join the Collaborative Business Experience __ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: 27 July 2006 16:50 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] R2 vs w2k3 SP1 (1) I remember seing it somewhere (while writing this, I remembered the location which can be found in the link below! ;-)) ). INTEGRATING R2 onto a server does impact that server. It just adds options to the Add/Remove Programs list. Installing one of the new options should not impact the server or other components within the infrastructure. Just like before you would be adding a new option to the server (e.g. adding the DHCP server role to it). However, SOME of the R2 options REQUIRE a schema change (DFS-R, UnixIDm, distributing printer connections through GPOs) and SOME of the R2 options REQUIRE the new .NET Framwork v2. For those two I say: test, test and test. As always implementing new technology requires testing, but just introducing an option, that option should not have that great of an impact. (2) ok, done (3) now I understand... If you just want to R2 servers from a network source by using the current source a change is needed. Remember... CD1 from the R2 distribution set is W2K3 with SP1 slipstreamed, BUT that media will also trigger the INTEGRATION of CD2 from the R2 distribution set. The NORMAL W2K3 with SP1 slipstreamed will not trigger that integration and that must therfore be triggered manually. From the R2 documentation placing the I386 dir (CD1) and the CMPNENTS dir (CD2) on the same network share should give you the possibility to install servers with the R2 binaries integrated (don't forget to use the R2 product key during the setup, otherwise during the integration you will need to enter the R2 key as well!!!). After that you still need to install the options manually or during install you need to specify what to install by using an answer file. For additional info also see: http://download.microsoft.com/download/4/e/d/4eda5dc2-2842-468e-834e-3756e4221cdb/Windows%20Server%202003%20R2%20Overview%20Guide.doc jorge From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, July 27, 2006 17:12 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] R2 vs w2k3 SP1 whenthe R2 binaries are installed on the server the only thing that happens is that the R2 options are INTEGRATED (not installed). The options still need to be installed additionally. So yes, the only differenceis the list in Add/Remove Programs. [Neil Ruston]is that documented as being the only change? I can see new login bitmaps etc which indicate (IMO) that certain files on CD1differ from the original w2k3 files. There is a small bug There will be a difference in tombstone lifetime depending on which server is used to create the forest. This is a bug within R2 that introduces an incorrect (nothing dangerous) SCHEMA.INI If you use a SP1 server to create the forest the tombstone lifetime will be 180 days If you use a R2 server to create the forest the tombstone lifetime will be60 days (not set), while 180 days is expected. [Neil Ruston]yep, discussed this internally already :) don't understand your 2nd Q [Neil Ruston]let's say I have a build source share which houses the server build and has sp1 slipstreamed into w2k3. I now wish to build r2 servers onlyand soI'm asked to slipstream r2 into that build repository. Is this even a meaningful statement? I ask because of the above and the fact that I believe an r2 server may appear differently to a w2k3 sp1 server even if CD2 is *not* applied. jorge From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, July 27, 2006 15:56 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] R2 vs w2k3 SP1 Question 1: Server 1 is built with R2 CD1. CD2 is not used at all. Server 2 is built with R2 CD1 and r2setup is executed from R2 CD2 as well. Will these 2 servers be configured differently in any way, other than the additional hooks in 'add/remove programs'? Question 2: If I have a build created with sp1 slipstreamed, does the statement 'slipstream R2 into the build' make any sense? I believe it does not make
RE: [ActiveDir] Migration without domain admin rights possible?
If the unit is this strongly separated from the rest of your forest and you have little dependencies on apps, this should be a fairly easy / straight forward migration. You should be able to achieve all steps with ADMT: The re-ACLing (= security translation) is actually a very straight forward process this is how I would go at it: 1. Create some test accounts in source domain that you put into group used by the users to be migrated a. Log on to a few test clients in source domain so as to create user source domain profiles (make some changes so that you can differentiate the profile from a default profile) 2. Migrate the units groups and users, but leave the users in the target domain disabled (except for some of the test-users) a. Users still logon to source domain 3. With the trusts between source and target still in place, migrate the resources (servers) a. Users still logon to source domain and access resources across trust, using SIDs from source domain 4. Perform 1st security translation on all resources (servers) a. Choose to ADD permissions b. Users still logon to source domain and access resources across trust, using SIDs from source domain c. Logon to a test computer in target domain with some of your test-accounts and check they also have access to servers (now using SIDs from target domain) d. If everything works, you are ready for activation of the target user accounts ideally the next two steps would be coordinated that you only enable the users whose workstations you are migrating at the time (but often difficult to match user to workstation) 5. Perform security translation AND profile updates on all workstations in unit again, use ADD permissions a. I personally prefer to do this prior to enabling the users and prior to migrating the computers this way this step can be performed in the background without any direct impact on the users b. This also allows you (or them) to monitor how well they can reach their clients, check access issues etc. c. Ensure that the computer updates especially profile updates have worked by using some of your test accounts on clients in the source domain: let them logon with the target domains account = they should at this point get the same user profile as before AND have access to the target servers 6. Once a critical mass of computers has been updated, you are ready to enable your users in the target domain 7. Now migrate the computers to target domain (those, where security translation has already been performed successfully) a. At this time there will be an impact to the users, since machines need to be rebooted which is why you should communicate these activities to your users prior to performing this step b. After the computer migration, ADMT will have changed the default logon domain to the target domain c. Users will now logon to the target domain and access resources with the new SIDs d. Add extra time for troubleshooting and fixing access issues 8. After all computers have been migrated, and all users of the unit logon to the target domain, you are ready to do the cleanup steps a. Cut the trusts between the domains (if this is what you want to achieve) b. Perform another security translation on all resources (servers and workstations) in the target domain = this time choose the REPLACE option 9. Done enjoy some champagne /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamlesh Parmar Sent: Thursday, July 27, 2006 4:57 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Migration without domain admin rights possible? Appreciate the quick response, I was able to migrate groups, users without sIDhistory to target. I also tried using clonepr.vbs, it also asks for admin rights on source. And reading further, it made it clear that, can't populate sIDhistory through legitimate APIs without having admin rights on source domain. So, now my hopes are based on security translation at each and every to be migrated resource. I will read up about PES service, so that if possible passwords also can be migrated without admin rights. In this case, no AD dependant app like exchange comes into picture. :-) this is more of completely independent unit with their own groups, users and computers contained within one OU. So group membership related stuff won't be problematic. (at least it seems on initial inspection) Anyway to make 2nd approach you mentioned more systematic and less painless? subinacl? ADMT security translation wizard? Thanks once again for your response, -- Kamlesh ~ Never confuse movement with action. ~ On 7/27/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: you can migrate most objects from the source even without admin rights to them - the default auth. user already has plenty of
Re: [ActiveDir] cn=meetings
Thanks On 7/27/06, Free, Bob [EMAIL PROTECTED] wrote: MS NetMeeting uses the Meetings container to publish network meetingobjects. From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Matheesha WeerasingheSent: Thursday, July 27, 2006 12:31 AMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] cn=meetingsAllJust a quick query. Does anyone know what cn=meetings,cn=system,dc=domainfqdn is for?CheersM@List info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Exchange rollout - How much larger does NTDS.DIT become?
Title: Exchange rollout - How much larger does NTDS.DIT become? Assuming this is after defrag, 650MB without Exchange is quite a large AD guess youd be close to 100k users in your forest, if youve used the standard attributes of the objects in AD (and havent added stuff like thumbnail pictures to your users). After adding the Exchange schema mods, the DIT shouldnt grow substantially, since AD doesnt use any space for unused attributes and the Exchange attributes for your object wont be filled magically, until you mail-enable them. But once they are filled, it will impact your AD (e.g. E2k3 adds 130 attributes to the Public Information property set used by user class objects) It is very tough to make a guess at the actual size youd have with a fully deployed Exchange, but if you do mail-enable the majority of your users (i.e. give them Exchange mailboxes) and add DLs etc. and assuming my guess with 100k users is in the right ballpark your AD DIT would easily grow to 3-5 GB. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RM Sent: Thursday, July 27, 2006 6:46 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Exchange rollout - How much larger does NTDS.DIT become? NTDS.DIT is currently 650megs. Once Exchange has been fully deployed, any guesses as to how much larger it will become? Just looking for a ballpark figure... thx, RM
Re: [ActiveDir] R2 vs w2k3 SP1
Uh... afaik R2 always has 2 disks (or thinks it should) On MSDN there's two disks for both Standard and Enterprise in the ISO downloads. Exactly what does this media look like? Guest, Mike wrote: As an interesting aside, We noticed recently that using an R2 corporate license key on a 2K3 enterprise (integrated sp1) CD causes the media to request the 2^nd disk – even though there is no second disk in the media kit.. (blame the reseller, who supplied us with the incorrect key) I’ve not had the opportunity (or enthusiasm) to test whether this is also the case with the standard edition __ Mike Guest | *Capgemini* | Sale Server Support | Outsourcing UK Office: + 44 (0)870 366 1814 | 700 1814 | [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]_ 77-79 Cross Street, Sale, Cheshire. M33 7HG *Join the Collaborative Business Experience* __ *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Almeida Pinto, Jorge de *Sent:* 27 July 2006 16:50 *To:* ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] R2 vs w2k3 SP1 (1) I remember seing it somewhere (while writing this, I remembered the location which can be found in the link below! ;-)) ). INTEGRATING R2 onto a server does impact that server. It just adds options to the Add/Remove Programs list. Installing one of the new options should not impact the server or other components within the infrastructure. Just like before you would be adding a new option to the server (e.g. adding the DHCP server role to it). However, SOME of the R2 options REQUIRE a schema change (DFS-R, UnixIDm, distributing printer connections through GPOs) and SOME of the R2 options REQUIRE the new .NET Framwork v2. For those two I say: test, test and test. As always implementing new technology requires testing, but just introducing an option, that option should not have that great of an impact. (2) ok, done (3) now I understand... If you just want to R2 servers from a network source by using the current source a change is needed. Remember... CD1 from the R2 distribution set is W2K3 with SP1 slipstreamed, BUT that media will also trigger the INTEGRATION of CD2 from the R2 distribution set. The NORMAL W2K3 with SP1 slipstreamed will not trigger that integration and that must therfore be triggered manually. From the R2 documentation placing the I386 dir (CD1) and the CMPNENTS dir (CD2) on the same network share should give you the possibility to install servers with the R2 binaries integrated (don't forget to use the R2 product key during the setup, otherwise during the integration you will need to enter the R2 key as well!!!). After that you still need to install the options manually or during install you need to specify what to install by using an answer file. For additional info also see: http://download.microsoft.com/download/4/e/d/4eda5dc2-2842-468e-834e-3756e4221cdb/Windows%20Server%202003%20R2%20Overview%20Guide.doc jorge *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of [EMAIL PROTECTED] *Sent:* Thursday, July 27, 2006 17:12 *To:* ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] R2 vs w2k3 SP1 when the R2 binaries are installed on the server the only thing that happens is that the R2 options are INTEGRATED (not installed). The options still need to be installed additionally. So yes, the only difference is the list in Add/Remove Programs. **[Neil Ruston] is that documented as being the only change? I can see new login bitmaps etc which indicate (IMO) that certain files on CD1 differ from the original w2k3 files.** There is a small bug There will be a difference in tombstone lifetime depending on which server is used to create the forest. This is a bug within R2 that introduces an incorrect (nothing dangerous) SCHEMA.INI If you use a SP1 server to create the forest the tombstone lifetime will be 180 days If you use a R2 server to create the forest the tombstone lifetime will be 60 days (not set), while 180 days is expected. **[Neil Ruston] yep, discussed this internally already :)** don't understand your 2nd Q **[Neil Ruston] let's say I have a build source share which houses the server build and has sp1 slipstreamed into w2k3. I now wish to build r2 servers only and so I'm asked to slipstream r2 into that build repository. Is this even a meaningful statement? I ask because of the above and the fact that I believe an r2 server may appear differently to a w2k3 sp1 server even if CD2 is *not* applied.** jorge *From:* [EMAIL
RE: [ActiveDir] R2 vs w2k3 SP1
Sorry, I don't think I made myself clear The KEY was R2, the MEDIA was W2K3 SP1 EE (ie NOT R2) __ Mike Guest | Capgemini | Sale Server Support | Outsourcing UK Office: + 44 (0)870 366 1814 | 700 1814 | [EMAIL PROTECTED] 77-79 Cross Street, Sale, Cheshire. M33 7HG Join the Collaborative Business Experience __ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: 28 July 2006 14:41 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] R2 vs w2k3 SP1 Uh... afaik R2 always has 2 disks (or thinks it should) On MSDN there's two disks for both Standard and Enterprise in the ISO downloads. Exactly what does this media look like? Guest, Mike wrote: As an interesting aside, We noticed recently that using an R2 corporate license key on a 2K3 enterprise (integrated sp1) CD causes the media to request the 2^nd disk - even though there is no second disk in the media kit.. (blame the reseller, who supplied us with the incorrect key) I've not had the opportunity (or enthusiasm) to test whether this is also the case with the standard edition __ Mike Guest | *Capgemini* | Sale Server Support | Outsourcing UK Office: + 44 (0)870 366 1814 | 700 1814 | [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]_ 77-79 Cross Street, Sale, Cheshire. M33 7HG *Join the Collaborative Business Experience* __ *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Almeida Pinto, Jorge de *Sent:* 27 July 2006 16:50 *To:* ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] R2 vs w2k3 SP1 (1) I remember seing it somewhere (while writing this, I remembered the location which can be found in the link below! ;-)) ). INTEGRATING R2 onto a server does impact that server. It just adds options to the Add/Remove Programs list. Installing one of the new options should not impact the server or other components within the infrastructure. Just like before you would be adding a new option to the server (e.g. adding the DHCP server role to it). However, SOME of the R2 options REQUIRE a schema change (DFS-R, UnixIDm, distributing printer connections through GPOs) and SOME of the R2 options REQUIRE the new .NET Framwork v2. For those two I say: test, test and test. As always implementing new technology requires testing, but just introducing an option, that option should not have that great of an impact. (2) ok, done (3) now I understand... If you just want to R2 servers from a network source by using the current source a change is needed. Remember... CD1 from the R2 distribution set is W2K3 with SP1 slipstreamed, BUT that media will also trigger the INTEGRATION of CD2 from the R2 distribution set. The NORMAL W2K3 with SP1 slipstreamed will not trigger that integration and that must therfore be triggered manually. From the R2 documentation placing the I386 dir (CD1) and the CMPNENTS dir (CD2) on the same network share should give you the possibility to install servers with the R2 binaries integrated (don't forget to use the R2 product key during the setup, otherwise during the integration you will need to enter the R2 key as well!!!). After that you still need to install the options manually or during install you need to specify what to install by using an answer file. For additional info also see: http://download.microsoft.com/download/4/e/d/4eda5dc2-2842-468e-834e-3756e42 21cdb/Windows%20Server%202003%20R2%20Overview%20Guide.doc jorge *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of [EMAIL PROTECTED] *Sent:* Thursday, July 27, 2006 17:12 *To:* ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] R2 vs w2k3 SP1 when the R2 binaries are installed on the server the only thing that happens is that the R2 options are INTEGRATED (not installed). The options still need to be installed additionally. So yes, the only difference is the list in Add/Remove Programs. **[Neil Ruston] is that documented as being the only change? I can see new login bitmaps etc which indicate (IMO) that certain files on CD1 differ from the original w2k3 files.** There is a small bug There will be a difference in tombstone lifetime depending on which server is used to create the forest. This is a bug within R2 that introduces an incorrect (nothing dangerous) SCHEMA.INI If you use a SP1 server to create the forest the tombstone lifetime will be 180 days If you use a R2 server to create the forest the
[ActiveDir] Can I add an index in AD using an LDIF file?
Title: Can I add an index in AD using an LDIF file?
I realise I could do this via the UI but I want to create a single LDIF which will:
Add new attributes
Make new attributes available to User class
Add new indexes
The last point evades me so far and the RFC appears to indicate that this is not supported(?)
Any ideas?
neil
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.
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 toearn 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] [EMAIL PROTECTED] 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.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
Re: [ActiveDir] Can I add an index in AD using an LDIF file?
Hey, I can post this one ahead of joe? joe must be busy or somethin' :)
I believe this is what you're looking for:
http://rallenhome.com/books/adcookbook/code.html
(see chapter 10 section for the vbs, ldif, and perl sections)
On 7/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
I realise I could do this via the UI but I want to create a single LDIF which will:
Add new attributes
Make new attributes available to User class
Add new indexes
The last point evades me so far and the RFC appears to indicate that this is not supported(?)
Any ideas?
neil
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.
RE: [ActiveDir] Can I add an index in AD using an LDIF file?
For the last one does including the following in the LDIF file when adding or
updating the attribute not accomplish what you want?
searchFlags: 1
Thanks,
-Steve
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Fri 7/28/2006 9:46 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Can I add an index in AD using an LDIF file?
I realise I could do this via the UI but I want to create a single LDIF which
will:
* Add new attributes
* Make new attributes available to User class
* Add new indexes
The last point evades me so far and the RFC appears to indicate that this is
not supported(?)
Any ideas?
neil
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.
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] 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Al
MulnickSent: 28 July 2006 16:08To:
ActiveDir@mail.activedir.orgSubject: 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 toearn 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] [EMAIL PROTECTED] 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.aspxList
FAQ: http://www.activedir.org/ListFAQ.aspxList
archive: http://www.activedir.org/ml/threads.aspxPLEASE 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.
[ActiveDir] RE: [ActiveDir] Read-Only Domain Controller and Server Core
I’m not sure why you say it doesn’t store anything??? It stores EVERYTHING, it simply doesn’t get the rights to write anything new back to your core DCs. This is a HUGE breakthrough for those of us with smaller branch offices that today can’t cost justify putting an entire server in a BO just to handle authentication, but at the same time we are not willing to open the security hole that is created if you put the DC services on a file server in those offices. With a RODC I can deploy authentication, as well as hopefully sites, etc. to those file servers without concern that a user might hack in and take over my AD. The number of doors this opens to a spread server architecture is really big. Granted, if you have no branch offices it won’t a thing to you. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Friday, July 28, 2006 10:08 AM To: ActiveDir@mail.activedir.org 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 toearn 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] [EMAIL PROTECTED] 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
RE: [ActiveDir] Can I add an index in AD using an LDIF file?
Yes it does :)
Thanks Steve and Al. [Robbie's stuff is very useful!]
neil
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Linehan
Sent: 28 July 2006 16:17
To: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Can I add an index in AD using an LDIF file?
For the last one does including the following in the LDIF file when
adding or updating the attribute not accomplish what you want?
searchFlags: 1
Thanks,
-Steve
From: [EMAIL PROTECTED] on behalf of
[EMAIL PROTECTED]
Sent: Fri 7/28/2006 9:46 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Can I add an index in AD using an LDIF file?
I realise I could do this via the UI but I want to create a single LDIF
which will:
* Add new attributes
* Make new attributes available to User class
* Add new indexes
The last point evades me so far and the RFC appears to indicate that
this is not supported(?)
Any ideas?
neil
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.
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.
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] R2 vs w2k3 SP1
Okay that makes more sense :-) Guest, Mike wrote: Sorry, I don't think I made myself clear The KEY was R2, the MEDIA was W2K3 SP1 EE (ie NOT R2) __ Mike Guest | Capgemini | Sale Server Support | Outsourcing UK Office: + 44 (0)870 366 1814 | 700 1814 | [EMAIL PROTECTED] 77-79 Cross Street, Sale, Cheshire. M33 7HG Join the Collaborative Business Experience __ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: 28 July 2006 14:41 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] R2 vs w2k3 SP1 Uh... afaik R2 always has 2 disks (or thinks it should) On MSDN there's two disks for both Standard and Enterprise in the ISO downloads. Exactly what does this media look like? Guest, Mike wrote: As an interesting aside, We noticed recently that using an R2 corporate license key on a 2K3 enterprise (integrated sp1) CD causes the media to request the 2^nd disk - even though there is no second disk in the media kit.. (blame the reseller, who supplied us with the incorrect key) I've not had the opportunity (or enthusiasm) to test whether this is also the case with the standard edition __ Mike Guest | *Capgemini* | Sale Server Support | Outsourcing UK Office: + 44 (0)870 366 1814 | 700 1814 | [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]_ 77-79 Cross Street, Sale, Cheshire. M33 7HG *Join the Collaborative Business Experience* __ *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Almeida Pinto, Jorge de *Sent:* 27 July 2006 16:50 *To:* ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] R2 vs w2k3 SP1 (1) I remember seing it somewhere (while writing this, I remembered the location which can be found in the link below! ;-)) ). INTEGRATING R2 onto a server does impact that server. It just adds options to the Add/Remove Programs list. Installing one of the new options should not impact the server or other components within the infrastructure. Just like before you would be adding a new option to the server (e.g. adding the DHCP server role to it). However, SOME of the R2 options REQUIRE a schema change (DFS-R, UnixIDm, distributing printer connections through GPOs) and SOME of the R2 options REQUIRE the new .NET Framwork v2. For those two I say: test, test and test. As always implementing new technology requires testing, but just introducing an option, that option should not have that great of an impact. (2) ok, done (3) now I understand... If you just want to R2 servers from a network source by using the current source a change is needed. Remember... CD1 from the R2 distribution set is W2K3 with SP1 slipstreamed, BUT that media will also trigger the INTEGRATION of CD2 from the R2 distribution set. The NORMAL W2K3 with SP1 slipstreamed will not trigger that integration and that must therfore be triggered manually. From the R2 documentation placing the I386 dir (CD1) and the CMPNENTS dir (CD2) on the same network share should give you the possibility to install servers with the R2 binaries integrated (don't forget to use the R2 product key during the setup, otherwise during the integration you will need to enter the R2 key as well!!!). After that you still need to install the options manually or during install you need to specify what to install by using an answer file. For additional info also see: http://download.microsoft.com/download/4/e/d/4eda5dc2-2842-468e-834e-3756e42 21cdb/Windows%20Server%202003%20R2%20Overview%20Guide.doc jorge *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of [EMAIL PROTECTED] *Sent:* Thursday, July 27, 2006 17:12 *To:* ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] R2 vs w2k3 SP1 when the R2 binaries are installed on the server the only thing that happens is that the R2 options are INTEGRATED (not installed). The options still need to be installed additionally. So yes, the only difference is the list in Add/Remove Programs. **[Neil Ruston] is that documented as being the only change? I can see new login bitmaps etc which indicate (IMO) that certain files on CD1 differ from the original w2k3 files.** There is a small bug There will be a difference in tombstone lifetime depending on which server is used to create the forest. This is a bug within R2 that introduces an incorrect (nothing dangerous) SCHEMA.INI If you use a SP1 server to create the forest the tombstone lifetime will be 180 days If you use a R2 server to create the forest the tombstone
[ActiveDir] schema extensions for Vista wireless networking GP support
In case anyone is interested, here's a doc that describes the AD schema extensions that will be required to support the new wireless networking Group Policy stuff in Vista: http://www.microsoft.com/technet/itsolutions/network/wifi/vista_ad_ext.mspx Darren Darren Mar-Elia For comprehensive Windows Group Policy Information, check out www.gpoguy.com-- the best source for GPO FAQs, video training, tools and whitepapers. Also check out the Windows Group Policy Guide,the definitiveresource for Group Policy information.
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 RODCs
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 admins responsibility to populate this
list. We might have some UI that helps with this process.
Once the hash is sent down, theres 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. Theres
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. Theres 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 dont 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:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Friday, July 28, 2006 8:22 AM
To: ActiveDir@mail.activedir.org
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@mail.activedir.org
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 toearn 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] [EMAIL PROTECTED]
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
RE: [ActiveDir] Read-Only Domain Controller and Server Core
To add a bit more The part that makes me wonder about the story is if it stores no secrets is the server doing anything for me? The short answer is yes. The bulk of the work that a DC does, even in the auth code path, may not involve the secret. So even if the secret checking work is outsourced to a hub DC, there is a lot more work that the local DC can perform for the user. For example, if it is an interactive logon, consider all of the GP work alone that is done that is now local. At the end of the day, you have a knob.you can make real security trade-offs based upon what attack surface you can accept mitigate, what administrative story you want, etc. You get to choose what secrets end up on the RODC. The product is built such that you can turn these knobs as you see fit but the default knob setting is more secure. I hope between my response and Dmitris you are clear that the belief that it stores nothing locally is incorrect. If more clarity is required please just holler. ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitri Gavrilov Sent: Friday, July 28, 2006 9:48 AM To: ActiveDir@mail.activedir.org 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 RODCs 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 admins responsibility to populate this list. We might have some UI that helps with this process. Once the hash is sent down, theres 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. Theres 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. Theres 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 dont 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, July 28, 2006 8:22 AM To: ActiveDir@mail.activedir.org 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: 28 July 2006 16:08 To: ActiveDir@mail.activedir.org 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 toearn 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] [EMAIL PROTECTED] 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
Re: [ActiveDir] Read-Only Domain Controller and Server Core
What conditions would make it so that the password policy would be configured such that the password replication was not allowed? Would that just be that the RODC is no longer trusted (i.e. it was abducted or otherwise compromised?)
Or is that something that some admin can configure and hurt themselves? Better yet, if that were true, is there any value left in the RODC that can't get a password hash?
On 7/28/06, Dmitri Gavrilov [EMAIL PROTECTED] wrote:
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
[EMAIL PROTECTED]Sent: Friday, July 28, 2006 8:22 AM
To: ActiveDir@mail.activedir.org
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:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Al MulnickSent: 28 July 2006 16:08To: ActiveDir@mail.activedir.orgSubject:
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 toearn 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] [EMAIL PROTECTED] 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
Re: [ActiveDir] RE: [ActiveDir] Read-Only Domain Controller and Server Core
To be completely fair, I'mNOTthe one that said that it doesn't store anything. I questioned that from the bloglink that was posted, because I know that itcan/does store some information which would make it useful.Not that you can get anything from that information, but then again, it's early in the adoption cycle (just before it really) so there hasn't been a large enough crowd to hammer away at it. Being highly familiar with BO environments, I agree it opens plenty of opportunity to deploy more DC's where before we could not. In some industries, that is far more important than others, but useful nonetheless. Note that my original concern was the way that the blog post mentioned the product and that it might be a deviation from the original story when the RODC concept was created and brought to life. I have seen the RODC before, but I am far more limited with what I can talk about and can't. Since I don't know what those limits are, I'm erring on the side of not even coming close to mentioning what I do and don't know nor some of the other questions that come to mind regarding that concept and it's boundaries. This is not the forum for that. On 7/28/06, Tim Vander Kooi [EMAIL PROTECTED] wrote: I'm not sure why you say it doesn't store anything??? It stores EVERYTHING, it simply doesn't get the rights to write anything new back to your core DCs. This is a HUGE breakthrough for those of us with smaller branch offices that today can't cost justify putting an entire server in a BO just to handle authentication, but at the same time we are not willing to open the security hole that is created if you put the DC services on a file server in those offices.. With a RODC I can deploy authentication, as well as hopefully sites, etc. to those file servers without concern that a user might hack in and take over my AD. The number of doors this opens to a spread server architecture is really big. Granted, if you have no branch offices it won't a thing to you. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Friday, July 28, 2006 10:08 AM To: ActiveDir@mail.activedir.org 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 toearn 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] [EMAIL PROTECTED] 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
Re: [ActiveDir] Read-Only Domain Controller and Server Core
More clarity is always welcome. I suspect I'm trying to get my mind around the GPO providing that much value that I would want to put a DC in the local brach as part of the design vs. trying really hard to use as little of the GPO as possible and making sure that the changes are as infrequent as possible. Authentication and name resolution are my biggest uses for a local DC in a branch. Outside of Exchange of course. Everything else I try to keep as compartmentalized as I can because if my WAN is a concern such that I can't use authentication across the wire (or can't trust it) then I have some big concerns about the branch environment and how autonomous it is. Outside of GP work what else comes to mind that is off-loaded to the local site that you can think of? Perhaps I'm looking at this sideways? On 7/28/06, Eric Fleischman [EMAIL PROTECTED] wrote: To add a bit more… The part that makes me wonder about the story is if it stores no secrets is the server doing anything for me? The short answer is yes. The bulk of the work that a DC does, even in the auth code path, may not involve the secret. So even if the secret checking work is "outsourced" to a hub DC, there is a lot more work that the local DC can perform for the user. For example, if it is an interactive logon, consider all of the GP work alone that is done that is now local. At the end of the day, you have a knob….you can make real security trade-offs based upon what attack surface you can accept mitigate, what administrative story you want, etc. You get to choose what secrets end up on the RODC. The product is built such that you can turn these knobs as you see fit but the default knob setting is "more secure". I hope between my response and Dmitri's you are clear that the belief that it stores "nothing locally" is incorrect. If more clarity is required please just holler. ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dmitri GavrilovSent: Friday, July 28, 2006 9:48 AM To: ActiveDir@mail.activedir.org 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED]Sent: Friday, July 28, 2006 8:22 AMTo: ActiveDir@mail.activedir.org 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: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al MulnickSent: 28 July 2006 16:08 To: ActiveDir@mail.activedir.orgSubject: 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 toearn 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
Re: [ActiveDir] DC Can't Handle DNS Pointed to Self
Stupid question? Is the network location awareness service running? We've found that XP machines picking up the policies from the server needed that service running. It should work with 'manual' but we've found that we've had to kick it to auto at times. Noah Eiger wrote: Hi Robert The firewall business comes from the fact that I have two domain-wide policies: if your computer is on one of the local networks, it gets no firewall; if it is off the network, it gets the firewall applied. Basically, it should not be processing that GPO that way. Something is amiss. _Dcdiag_ shows passes except for 1) failures to replicate to the other local DC, but success to the bridgehead at the hub site. 2) this KCC error: Starting test: kccevent An Warning Event occured. EventID: 0x80250828 Time Generated: 07/27/2006 22:31:03 (Event String could not be retrieved) .. VDC02 failed test kccevent _Netdiag_ failures are: Per interface results: Adapter : Local Area Connection Netcard queries test . . . : Passed Host Name. . . . . . . . . : VDC02 IP Address . . . . . . . . : 10.30.100.34 Subnet Mask. . . . . . . . : 255.255.255.0 Default Gateway. . . . . . : 10.30.100.1 Primary WINS Server. . . . : 10.10.200.30 Secondary WINS Server. . . : 10.10.200.31 Dns Servers. . . . . . . . : 10.30.100.34 AutoConfiguration results. . . . . . : Passed Default gateway test . . . : Passed NetBT name test. . . . . . : Passed [WARNING] At least one of the 00 'WorkStation Service', 03 'Messenger Service', 20 'WINS' names is missing. WINS service test. . . . . : Passed Trust relationship test. . . . . . : Failed [FATAL] Secure channel to domain 'CORPCO' is broken. [ERROR_NO_LOGON_SERVERS] NetBT name test. . . . . . . . . . : Passed [WARNING] You don't have a single interface with the 00 'WorkStation Service', 03 'Messenger Service', 20 'WINS' names defined. Finally, all this could be related to the _virtual machine portion_ of things. The host machine shows several informational messages in the System Log related to VPCNetS2 (errors 5, 10, 12, and 13). Googling indicates these might be creating confusion between the host, the guest, and the network. Thanks, --- nme *From:* Robert Rutherford [mailto] *Sent:* Friday, July 28, 2006 12:20 AM *To:* ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] DC Can't Handle DNS Pointed to Self Sounds like its not replicating. When you say non-domain firewall, what do you mean? You don’t want any firewall on it… unless you have a specific need. If you strip the firewall off, where does that leave you? If you use dcdiag and netdiag they should also give you an idea about what’s going on. If you like, feel free to mail them to me. Cheers, Rob *Robert Rutherford* *QuoStar Solutions Limited* The Enterprise Pavilion Fern Barrow Wallisdown Poole Dorset BH12 5HH *T:* +44 (0) 8456 440 331 *F:* +44 (0) 8456 440 332 *M:* +44 (0) 7974 249 494 *E: * [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *W: * www.quostar.com http://www.quostar.com *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Noah Eiger *Sent:* 28 July 2006 07:20 *To:* ActiveDir@mail.activedir.org *Subject:* [ActiveDir] DC Can't Handle DNS Pointed to Self Hello: This is sort of a follow up to two recent postings. Any thoughts are welcome as I have now been trying to figure this one out for about a week. I have DC running as a virtual machine under (host W2k3 SP1 w/ VS 2005 R2; guest: W2k3 ENT R2). This machine was recently promoted. When its local DNS points to itself, the machine does not logon to the domain. It appears to not even know about itself. No one can get to it because it loads the non-domain firewall GPO (enabling the full firewall). When I point DNS across the WAN, it loads – though interestingly it does not become visible on the network until I log into it (via the VS management tools). I can then log out and it stays visible. It then appears to function correctly. Any thoughts greatly appreciated. -- nme -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/399 - Release Date: 7/25/2006 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/399 - Release Date: 7/25/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/399 - Release Date: 7/25/2006 --
RE: [ActiveDir] Read-Only Domain Controller and Server Core
Hi Al, Take your workstation and take a sniff of a logon. All traffic you throw at the DC will work against the RODC. The only WAN traffic in that scenario would be the auth itself, a tiny amt of work. (assuming GC and all that is satisfied locally) So, the statement that authentication is your biggest use is true, kindayou need to more carefully define the operation. I suspect you dont mean auth in the Kerberos sense, you mean user logon really. Unless your branch has a bunch of apps that do Kerb work and no clients.then you can correct me and we have a totally different conversation on our hands. :) Answering some questions of yours, from this and other forks of the thread.. What conditions would make it so that the password policy would be configured such that the password replication was not allowed? There is a policy (not group policy, administrative one defined in AD itself) which defines what can be cached there and what can not. The statement made (I think first by Dmitri, but I then commented on it further) was that by default, this policy allows almost nothing to be cached. You could tweak this in your enterprise and change what is cached, anything from the near-nothing default to almost every secret in the domain. You can choose. Would that just be that the RODC is no longer trusted (i.e. it was abducted or otherwise compromised?) Well, we never know if an RODC was compromised. Rather, RODC was built such that you the admin can assume they are compromised, and fully understand the scope of compromise in your enterprise should it happen one day, and respond to said event. So, I say you should look at this problem the other way. Treat your RODCs as if they were about to get compromised, then make real decisions around how much work the recovery from said compromise would be vs. actually having an environment that is useful, reliable, easy to manage, etc. Thats what I was talking about re: the knobs.you can turn said knobs and make decisions that work for you. And well have documentation that will help you do this. Or is that something that some admin can configure and hurt themselves? Better yet, if that were true, is there any value left in the RODC that can't get a password hash? I think I answered this but please holler if it is still unclear. Outside of GP work what else comes to mind that is off-loaded to the local site that you can think of? Take a network sniff of your clients talking to your DCs for a day. Almost all of that stuff. J You could have apps, you have logon itself, etc. Perhaps I'm looking at this sideways? Every environment is different. It is entirely possible that a secret-less RODC is totally uninteresting in your enterprise. That said, I would argue that you probably havent done enough investigation yet to really know if thats true or notits not personal, why would you? This has likely never been relevant. Almost no one does this sort of analysis unless they absolutely have to. Take some data, please report back to us. Id love to look at said data with you if youre unclear as to what would fall in what bucket. Hope this helps. Please holler back with questions. ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Friday, July 28, 2006 10:34 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core More clarity is always welcome. I suspect I'm trying to get my mind around the GPO providing that much value that I would want to put a DC in the local brach as part of the design vs. trying really hard to use as little of the GPO as possible and making sure that the changes are as infrequent as possible. Authentication and name resolution are my biggest uses for a local DC in a branch. Outside of Exchange of course. Everything else I try to keep as compartmentalized as I can because if my WAN is a concern such that I can't use authentication across the wire (or can't trust it) then I have some big concerns about the branch environment and how autonomous it is. Outside of GP work what else comes to mind that is off-loaded to the local site that you can think of? Perhaps I'm looking at this sideways? On 7/28/06, Eric Fleischman [EMAIL PROTECTED] wrote: To add a bit more The part that makes me wonder about the story is if it stores no secrets is the server doing anything for me? The short answer is yes. The bulk of the work that a DC does, even in the auth code path, may not involve the secret. So even if the secret checking work is outsourced to a hub DC, there is a lot more work that the local DC can perform for the user. For example, if it is an interactive logon, consider all of the GP work alone that is done that is now local. At the end of the day, you have a knob.you can make real security trade-offs based upon what attack surface
RE: [ActiveDir] ldp in ADAM-SP1
Dmitri, first of all, I should have added to this thread that there are actually already a couple of nice changes in DSACLS in Longhorn, which I am glad do exist: - it can now be used to set Control Access rights on attributes (for example with confidential attributes) - it allows to use SIDs and FQDNs to set/remove ACLs (SID is a major benefit) - it supports setting the new OWNER RIGHTS permissions (which can't be set via the UI right now) However, the thing I think is still extremely annoying is that you can't remove single permissions - you always have to remove ALL permissions for a specific security principal (on the object that you're processing). This makes it extremely difficult to automate removal of permissions, as I first need to check all the permissions that an sec prin has, then remove the one permission that I'd like to remove and at least re-apply all the permissions that I didn't want to remove. Quite a pain - would be great to fix this. At last, it would be nice to combine the feature of DSACLS with that of DSREVOKE. The latter is useful to report on ACLs for a single sec prins in a whole tree (and to remove them) - however, it is incapable of doing so for well-known-security-principals such as Authenticated Users or built-in ones such as Administrators. Would be lovely to see these changes in B3 ;-) /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitri Gavrilov Sent: Thursday, July 27, 2006 7:46 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Guido, which changes to you want to see in dsacls in B3? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, July 25, 2006 6:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you should need to do. You've already tripped over some of it's limitations especially around handling the confidential bit - however, I have not seen many customers that actually leverage the confidential bit yet for anything else but OS features (for example for PKI credential roaming). It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. For file-system ACLing that tool is CALS or XCACLS - probably for 99% of what you need to do. Note for the FS you may also want to check out the betas of either Windows Longhorn or the current Windows 2003 SP2 = they include a new commandline ACLing tool called Icacls.exe, which can be used to reset the account control lists (ACL) on files from Recovery Console, and to back up ACLs. It can also handle replacement of ACLs (much like subinacl) and works well with either names or SIDs. At last, unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and thus correctly propagates changes to and creation of inherited ACLs. DSACLs has only been updated slightly in LH, but I hope to see some more changes prior to beta 3. At last, depending on your requirements, you may also need to look into changing the default security descriptor of some of the objects (for example, check out all the default write permissions, which every user is granted on it's own object via the SELF security principal; many companies are still unaware of this). You can check these rights most easily via the schema mgmt mmc (check properties of a class object, such as user and click on the Default Security tab). So it's fair to say that although handling ACLs remains to be a complex topic, you can get most of the things done with existing commandline tools from MSFT. Sometimes it will simply be more appropriate to use the UI for a few settings. And there is always the option to script setting ACLs if you really have special requirements. As for your delegation model = I would not have the goal to teach your delegated admins how to do ACLing inside AD. I'm fine with a delegated admin doing the security on a file-server that he completely manages on his own. But AD security should be kept in the hand of domain and enterprise admins (partly because it is rather complex and you only want few folks to fiddle around with it, partly because it is plain risky to do it otherwise). The critical piece for most delegation models to succeed is to build a centrally controlled OU structure (ideally standardized for your different delegated admin units as I like to call them and not to grant your data admin (= the delegated admins) any rights to create OUs themselves (otherwise - with the current ACLing model - you can't prevent them to configure the security of the OU). Basically the same is true for any objects they create, but it's the OUs that allow you to manage the security for
RE: [ActiveDir] Read-Only Domain Controller and Server Core
Could be worth to note that an RODC can also be a DNS server for the respective BO. As it is designed for one-way replication from a writeable DC, it does not allow direct dynamic updates of DNS records that are requested to be updated by clients that use the RODC as a DNS server (same is true for password changes) = these are basically forwarded to the next writeable DC and then replicated back to the RODC. Sounds complicated, but makes sense as the RODC should be regarded as an untrusted DC. I am certainly a friend of combining RODC with Server Core for BO environments. Combine this with the Admin Separation features of RODC and you have a great BO story. Admin Separation means that you can make a non-domain admin a member of the local admin group on an RODC, without granting him/her admin rights in AD. Server Core will obviously not only be useful for BOs they can also host writeable DCs in a companys datacenters. Biggest challenge I see is configuring the policies for storing credentials on RODCs its the typical challenge of matching mobile objects (users and notebooks) to non-mobile devices (an RODC in a site). And currently this is all based on group memberships. I hope to see an option coming up to use OUs instead. I do agree with Al, that the original blog entry that started this discussion was a little misleading and didnt do the features of RODC justice. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Friday, July 28, 2006 9:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Hi Al, Take your workstation and take a sniff of a logon. All traffic you throw at the DC will work against the RODC. The only WAN traffic in that scenario would be the auth itself, a tiny amt of work. (assuming GC and all that is satisfied locally) So, the statement that authentication is your biggest use is true, kindayou need to more carefully define the operation. I suspect you dont mean auth in the Kerberos sense, you mean user logon really. Unless your branch has a bunch of apps that do Kerb work and no clients.then you can correct me and we have a totally different conversation on our hands. :) Answering some questions of yours, from this and other forks of the thread.. What conditions would make it so that the password policy would be configured such that the password replication was not allowed? There is a policy (not group policy, administrative one defined in AD itself) which defines what can be cached there and what can not. The statement made (I think first by Dmitri, but I then commented on it further) was that by default, this policy allows almost nothing to be cached. You could tweak this in your enterprise and change what is cached, anything from the near-nothing default to almost every secret in the domain. You can choose. Would that just be that the RODC is no longer trusted (i.e. it was abducted or otherwise compromised?) Well, we never know if an RODC was compromised. Rather, RODC was built such that you the admin can assume they are compromised, and fully understand the scope of compromise in your enterprise should it happen one day, and respond to said event. So, I say you should look at this problem the other way. Treat your RODCs as if they were about to get compromised, then make real decisions around how much work the recovery from said compromise would be vs. actually having an environment that is useful, reliable, easy to manage, etc. Thats what I was talking about re: the knobs.you can turn said knobs and make decisions that work for you. And well have documentation that will help you do this. Or is that something that some admin can configure and hurt themselves? Better yet, if that were true, is there any value left in the RODC that can't get a password hash? I think I answered this but please holler if it is still unclear. Outside of GP work what else comes to mind that is off-loaded to the local site that you can think of? Take a network sniff of your clients talking to your DCs for a day. Almost all of that stuff. J You could have apps, you have logon itself, etc. Perhaps I'm looking at this sideways? Every environment is different. It is entirely possible that a secret-less RODC is totally uninteresting in your enterprise. That said, I would argue that you probably havent done enough investigation yet to really know if thats true or notits not personal, why would you? This has likely never been relevant. Almost no one does this sort of analysis unless they absolutely have to. Take some data, please report back to us. Id love to look at said data with you if youre unclear as to what would fall in what bucket. Hope this helps. Please holler back with questions. ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Friday, July 28, 2006 10:34 AM To:
RE: [ActiveDir] ldp in ADAM-SP1
Thanks Guido, Nice requests, but not small. So, no promises for LH, it is getting late. I'll get these filed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Friday, July 28, 2006 1:06 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Dmitri, first of all, I should have added to this thread that there are actually already a couple of nice changes in DSACLS in Longhorn, which I am glad do exist: - it can now be used to set Control Access rights on attributes (for example with confidential attributes) - it allows to use SIDs and FQDNs to set/remove ACLs (SID is a major benefit) - it supports setting the new OWNER RIGHTS permissions (which can't be set via the UI right now) However, the thing I think is still extremely annoying is that you can't remove single permissions - you always have to remove ALL permissions for a specific security principal (on the object that you're processing). This makes it extremely difficult to automate removal of permissions, as I first need to check all the permissions that an sec prin has, then remove the one permission that I'd like to remove and at least re-apply all the permissions that I didn't want to remove. Quite a pain - would be great to fix this. At last, it would be nice to combine the feature of DSACLS with that of DSREVOKE. The latter is useful to report on ACLs for a single sec prins in a whole tree (and to remove them) - however, it is incapable of doing so for well-known-security-principals such as Authenticated Users or built-in ones such as Administrators. Would be lovely to see these changes in B3 ;-) /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitri Gavrilov Sent: Thursday, July 27, 2006 7:46 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Guido, which changes to you want to see in dsacls in B3? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, July 25, 2006 6:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you should need to do. You've already tripped over some of it's limitations especially around handling the confidential bit - however, I have not seen many customers that actually leverage the confidential bit yet for anything else but OS features (for example for PKI credential roaming). It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. For file-system ACLing that tool is CALS or XCACLS - probably for 99% of what you need to do. Note for the FS you may also want to check out the betas of either Windows Longhorn or the current Windows 2003 SP2 = they include a new commandline ACLing tool called Icacls.exe, which can be used to reset the account control lists (ACL) on files from Recovery Console, and to back up ACLs. It can also handle replacement of ACLs (much like subinacl) and works well with either names or SIDs. At last, unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and thus correctly propagates changes to and creation of inherited ACLs. DSACLs has only been updated slightly in LH, but I hope to see some more changes prior to beta 3. At last, depending on your requirements, you may also need to look into changing the default security descriptor of some of the objects (for example, check out all the default write permissions, which every user is granted on it's own object via the SELF security principal; many companies are still unaware of this). You can check these rights most easily via the schema mgmt mmc (check properties of a class object, such as user and click on the Default Security tab). So it's fair to say that although handling ACLs remains to be a complex topic, you can get most of the things done with existing commandline tools from MSFT. Sometimes it will simply be more appropriate to use the UI for a few settings. And there is always the option to script setting ACLs if you really have special requirements. As for your delegation model = I would not have the goal to teach your delegated admins how to do ACLing inside AD. I'm fine with a delegated admin doing the security on a file-server that he completely manages on his own. But AD security should be kept in the hand of domain and enterprise admins (partly because it is rather complex and you only want few folks to fiddle around with it, partly because it is plain risky to do it otherwise). The critical piece for most delegation models to succeed is to build a centrally controlled OU structure (ideally standardized for your different delegated admin units as I like to
