RE: [ActiveDir] moving server local groups to AD?
ADMT (even in V3) doesn't support this directly, however, you can still use it to do the re-ACLing if you want, since you can feed it with a list of SID mappings. You would still have to perform the bulk of the work yourself, which would be to re-create matching groups in AD and to add the members of the server-local groups to the AD groups. While doing this, you'd create your SID mapping-file. I know that Quest's DMW tool has the capability to do all of this for you (i.e. migrate server local groups to AD incl. membership and re-ACLing the server appropriately) - but you might also want to Google around a little for scripts that serve this purpose. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thommes, Michael M. Sent: Donnerstag, 25. Januar 2007 04:19 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] moving server local groups to AD? (I sure hope this doesn't sound like too dumb a question!) We have a server where local security groups were created for local file access. The files on this server are going to be moved to a file server cluster. Can ADMT v3 migrate these security groups up to the AD structure with the hopes of retaining SIDHistory and therefore access to the moved files? If ADMT wouldn't work, does anyone have suggestions for this operation? As always, any help is appreciated! Mike Thommes
RE: [ActiveDir] Add or Remove Programs GPO
What other things did you change in the same or other GPOs that apply to the machine you're logging on as admin? If you've applied some lockdown GPOs for file-system permissions, those will also apply for your admins /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bart Van den Wyngaert Sent: Mittwoch, 24. Januar 2007 17:38 To: ActiveDir Subject: [ActiveDir] Add or Remove Programs GPO Hi, I've set a GPO for some users that restricts usage of Add or Remove Programs (User Configuration\Administrative Templates\Control Panel\Add or Remove Programs). This GPO is linked to a specific OU where those users reside. But now I have even with admin accounts to which the GPO doesn't apply (totally different OU location and so on...) problems with opening the interface, it refers to security that is not correct on C:\WINNT\System32\rundll32.exe Is this normal?! Did I miss something before setting this GPO? Thanks, Bart
RE: [ActiveDir] Add or Remove Programs GPO
So what is the NTFS security on C:\WINNT\System32\rundll32.exe? The error message could naturally be a false hint, but might as well check it out. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bart Van den Wyngaert Sent: Donnerstag, 25. Januar 2007 12:00 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Add or Remove Programs GPO No NTFS or other restrictions set in that GPO or the PC GPO. Only some other restrictions like no access to control panel, no messenger, ... stuff. These apply to the specific Users OU + Computer OU, making a User PC configuration for those PC's + Users (certain department). My admin account is totally somewhere else in the directory without those GPO's applied to. The restrictions in the Computer GPO are also not set to block the admin. I can drilldown the Computer GPO if you want, as I don't see any relevant setting in it. Otherwise I would be blocking myself and that's just the point I don't want... Thanks, Bart On 1/25/07, Grillenmeier, Guido [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: What other things did you change in the same or other GPOs that apply to the machine you're logging on as admin? If you've applied some lockdown GPOs for file-system permissions, those will also apply for your admins /Guido From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Bart Van den Wyngaert Sent: Mittwoch, 24. Januar 2007 17:38 To: ActiveDir Subject: [ActiveDir] Add or Remove Programs GPO Hi, I've set a GPO for some users that restricts usage of Add or Remove Programs (User Configuration\Administrative Templates\Control Panel\Add or Remove Programs). This GPO is linked to a specific OU where those users reside. But now I have even with admin accounts to which the GPO doesn't apply (totally different OU location and so on...) problems with opening the interface, it refers to security that is not correct on C:\WINNT\System32\rundll32.exe Is this normal?! Did I miss something before setting this GPO? Thanks, Bart
RE: [ActiveDir] Who needs that much ram anyway?
So you might have had a bit too much of the Microsoft Cool-Aid :) Exchange 2007 may not have memory limits that you'd reach - but there are limits as to what makes sense to use with E2k7 (32GB are being communicated by MSFT). And of course there are limits as to how much memory a 64bit OS supports: theoretically you could address a max of 16 exa-bytes with a 64bit address space, that is 16 billion GB... - however, the 64bit Windows OSs only support up to 16 TB virtual address space (split half/half for kernel and user memory) and only up to 1TB RAM (will increase to 2TB with SP2). Don't misunderstand the term only here, since there isn't much Windows hardware out there that can cope with more than 1TB of RAM right now anyways. Not to say that these are any limits that you'd reach anytime soon with Exchange 2007. Note that the /3GB switch is not supported on Windows 64bit Oss - there is no reason to use it either, since both the virtual kernel and the user-memory are increased dramatically (up to 8 TB each). The /3GB switch is used on 32bit boxes to influence how the max of 4GB virtual memory that is addressable by 32bit is split up between kernel and user memory - you increase the user memory (used by apps such as Exchange) at the cost of reducing the kernel memory. This is no longer required with 64bit boxes... /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Brunson Sent: Dienstag, 16. Januar 2007 23:48 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Who needs that much ram anyway? Judging by the Exchange 2007 Microsoft Across America Launch Event that I attended this morning, Exchange 2007 has no limits period. If you want it to block spam, it blocks spam. If you want it to run with a 2000TB store on Standard, it will do it. If you want it to cook you breakfast, that might require the /baconandeggs switch, but it should be able to do that as well. The /baconandeggs switch might be undocumented... Seriously though, I know PAE is not supported on 64-bit, and I think I remember reading that /3GB is required on 64-bit OS -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jose Medeiros Sent: Tuesday, January 16, 2007 4:04 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Who needs that much ram anyway? What about the 3Gb switch in the boot.in that is required to take advantage of the additional memory. Also depending on the age of the server and CPU, you may also need a PAE / AWE switch. http://support.microsoft.com/kb/283037 Since the final realease of Exchange 2007 will only be 64 bit and require a 64 bit version of Windows 2003 or Longhorn, I am not sure if the switch will be required, any one else know? Jose - Original Message - From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Tuesday, January 16, 2007 8:47 AM Subject: Re: [ActiveDir] OT: Who needs that much ram anyway? Personally I was surprised that a Windows 2003 server and Exchange 2007 would need a patch to run more than 4 gigs because This problem occurs because of a problem in the Windows kernel Seems to me in the x64 era, we're all going to be running more than 4 gigs so they should bundle this up in the Exchange 2007 installer from the get go rather than having everyone stumble across a KB article. I'm assuming it's discussed in the readme that no one reads? Brian Desmond wrote: The more you can get in memory, the better. 32GB is the threshold for Exchange before it stops making sense. I've remoted into SQL servers with dozens of CPUs and dozens of gigs of ram before... Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 -Original Message- From: [EMAIL PROTECTED] [mailto:ActiveDir- [EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Tuesday, January 16, 2007 4:01 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] OT: Who needs that much ram anyway? The Microsoft Exchange Information Store service stops responding on a computer that is running Windows Server 2003 and Exchange Server 2007 http://support.microsoft.com/?kbid=928368 This problem occurs if Exchange Server 2007 is installed on a computer that has more than 4 gigabytes (GB) of RAM. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx -- Letting your vendors set your risk analysis these days? http://www.threatcode.com If you are a SBSer and you don't subscribe to the SBS Blog... man ... I will hunt you down... http://blogs.technet.com/sbs List info : http://www.activedir.org/List.aspx List FAQ
RE: [ActiveDir] OT: Sorta... AD and the 3/07 Time Change
Happy New Year to you too J Mexico hasn't joined in, which is why it's a bit of a hassle if you have machines in Mexico as well: right now they use the same time zone as used in the US [(GMT-08) Tijuana, Baja California]. But since they're not jumping on the time zone change track, MSFT will introduce a new time zone for Mexico which the Mexican machines will have to be adjusted for to use (which is obviously not the same thing as just updating the time zone tables with new values for daylight savings time). As was mentioned before, being in a domain ensures UTC time sync - but the local settings on the clients determine it's time zone and daylight savings configuration. The more important part in an AD domain is that machines aren't fixed manually, once March 11th comes around... Meaning to say if an admin notices that the clock is off by an hour on a server (due to a missing patch which would have adjusted the DST values), then the admin shouldn't correct the time manually - the Kerberos protocol is not very forgiving for a skew of an hour. Users would not be able to reach the server and if this is a DC, replication with other DCs would fail as well. You'd have all sorts of lovely issues authentication issues... Which is why - besides ensuring that all machines are updated appropriately - you should teach your admins how to properly handle a manual change in case it is necessary (i.e. how to adjust the DST values). BTW, don't forget to update your PDAs and other mobile devices that connect to your network and sync with Exchange: they'll be your primary reason for false meeting schedules etc. Ha, March 11 and the following 3 weeks are going to be so much fun, and so will the first week in November J I wonder if anyone ever thought about the energy spent for this change of DST vs. the energy saved by it... /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Kline Sent: Sonntag, 31. Dezember 2006 21:45 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] OT: Sorta... AD and the 3/07 Time Change This question addresses the March'07 Dailylight Saving's time change in the US and Canada (has Mexico joined in?). I work for an institute of higher learning where the policies (human, not domain) get a little... unevenly suggested. So please grant me some leniency as to why this question is even asked :) Does belonging to a domain with properly configured time synchronization lessen the concern for applying the XP patches as they relate to the March 2007 time change? Or the need to take special care with Windows 2000 workstations? In other words, will AD sync the PC clock on Windows 2000 workstations to the correct hour during next next March's leap ahead Speaking of time: Happy New Year to Everyone! Thank you. Richard
RE: [ActiveDir] Delegate Password Resets
Why would you want to modify the change password rights on your OUs? That doesn't make sense to delegate: unlike password reset, it's the right that only allows you to _change_ the password if you know the old one... So this is typically what the rights the users would need to change the PW on their own account - and by default it's granted to the Everyone well-known-secprin. This is NOT a security issue since if you know a user's password, you _are_ the user. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN Sent: Freitag, 22. Dezember 2006 06:38 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Delegate Password Resets In our case, I simply modified the security permissions on the OU containing our user accounts to provide a granular delegation of rights so the members of this security group can go into ADUC and unlock user accounts or reset/change passwords only. I modified various read/write property rights as well as reset password and change password rights. Besides modifying ACLs, what other methods of delegating password reset functions were you referring to? From: [EMAIL PROTECTED] on behalf of Salandra, Justin A. Sent: Thu 12/21/2006 6:24 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Delegate Password Resets I wanted to find out from all of you what ways you have delegated password reset functions to your helpdesks. We have a product that does this but it is continually having problems and want to know if there are nay other ways. Justin A. Salandra MCSE Windows 2000 and 2003 Network and Technology Services Manager Catholic Health Care System 646.505.3681 cell 917.455.0110 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]
RE: [ActiveDir] Delegate Password Resets
That's a legacy group from NT4 that you shouldn't leverage in an AD environment. In fact, you should remove it from the default security descriptor of your user and group objects to keep your AD clean from unused ACEs. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Miller Sent: Freitag, 22. Dezember 2006 16:39 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Delegate Password Resets I put the user accounts of the helpdesk personnel in the built in group, Account Operators. This is precisely why I think that group exists. -mjm Salandra, Justin A. wrote: I wanted to find out from all of you what ways you have delegated password reset functions to your helpdesks. We have a product that does this but it is continually having problems and want to know if there are nay other ways. Justin A. Salandra MCSE Windows 2000 and 2003 Network and Technology Services Manager Catholic Health Care System 646.505.3681 cell 917.455.0110 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/
RE: [ActiveDir] Built in Security groups
Not putting any users in the groups is basically the same effect as removing them from an operational perspective. If you don't have a user in the group, nobody has the rights to change things that only these groups have rights to. That's probably what your mgmt wants to achieve. You'd then populate the groups on a as-needed basis to perform specific tasks. The reason why you don't want to remove them (which you could technically) is pretty easy: these groups are there for a purpose, i.e. they have been granted specific rights in AD to perform special tasks. This includes schema mgmt and administration of the config NC. If you don't like the groups, you'd have to ACL AD to allow another group to perform the tasks - doesn't really make any sense ... /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Freitag, 22. Dezember 2006 17:14 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Built in Security groups Does anyone have a reference (preferably from MS) showing that you should not remove the Built in Security groups such as Schema Admins, Enterprise Admins, etc. It has come down from above that we should be removing these groups and while I know better I need some ammunition to back me up. Thanks, Andrew Fidel
RE: [ActiveDir] Delegate Password Resets
I don't - I like leveraging the capabilities of AD and this is something where it can perform quite well. That's not true for other things you can delegate, such as creation of objects, where you might really want to add a business logic. These actions are often combined these days with provisioning tools. But for resetting passwords in a strongly distributed environment, where you may want to delegate PW mgmt to specific branches in your company, I prefer to use the native AD rights and have the change happen on a DC close to the user. Specifically for lockout and user-must-change-pw actions, since these are not handled/replicated the same way as pw-resets. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Freitag, 22. Dezember 2006 18:33 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Delegate Password Resets You will either delegate or you will proxy. That is about it for the choices. And quite frankly, the proxy is just a delegation to a specific account that does the authentication/authorization of the support folks on its own. To be most honest, I prefer proxy over delegation. It is much easier to track and control and enforce some kind of business logic. I much prefer to stop people up front than try to track later what the heck happened. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salandra, Justin A. Sent: Thursday, December 21, 2006 9:25 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Delegate Password Resets I wanted to find out from all of you what ways you have delegated password reset functions to your helpdesks. We have a product that does this but it is continually having problems and want to know if there are nay other ways. Justin A. Salandra MCSE Windows 2000 and 2003 Network and Technology Services Manager Catholic Health Care System 646.505.3681 cell 917.455.0110 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]
RE: [ActiveDir]Groups
We have a tool that does this (although this is not its main feature), but it's not free. It's actually a backup tool of all links in your AD forest (i.e. all domains in the forest). As we store all of these in an SQL DB, we can easily run reports on group-nesting across the whole forest, including all domain local groups in any domain. The main purpose is obviously to have this information available in case you need to restore the group-links (which there are plenty of reasons for, especially in an auth-restore case). /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cothern, Jeffrey D Mr CTR USSOCOM HQ Sent: Donnerstag, 21. Dezember 2006 16:12 To: ActiveDir@mail.activedir.org Subject: [ActiveDir]Groups Greetings I am having to setup groups within our AD structure using AGDLP method. We are doing it in a way to follow or organization structure. This of course is creating a lot of groups. To ensure that I have the groups nested correctly I am looking for a way to easily get a graphical representation or excel spreadsheet with data from AD showing the nested groups. I have looked at many scripts and also using DSget but it doesn't give me all the information that I need. I either get all the users that are nested in subgroups but it doesn't tell me which group those users are a member of. I found another script that actually puts text next to the users telling me which nested group they are a member of but then it doesn't show me any nested groups that are currently empty. Does anyone know of a utility out there that may show me the members of groups and the groups those groups are members of etc. Jeff List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/
RE: [ActiveDir] OT: Let's see how many wrong things are in this web site
They're mixing up different statements and rephrase them to their advantage - it is true that SBS doesn't support a second SBS DC in the same domain/forest (as every SBS has to hold all FSMOs), but another non-SBS server can act as a second DC in the SBS forest just fine. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Mittwoch, 20. Dezember 2006 08:04 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] OT: Let's see how many wrong things are in this web site http://utools.com/help/MovingSBS.asp SBS is limited to 5-20 users -- try 75 users or devices Because SBS does not allow a second domain controller, there is no supported way to back up Active Directory to protect against failure of the SBS computer. --- Firstly, SBS supports additional domain controllers.. and have for years... as far as a supported way to backup AD... last I checked there's this new fangled thing called System state backup... kinda a reliable way to back up AD last I heardand in fact there's a SBS wizard that backs up the entire system. UMove is the *only* utility that can recover Active Directory when running a standalone Small Business Server. --- my guess is there are some guys on this list that would disagree with that statement List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/
RE: [ActiveDir] How to completely isolate a DC?
This is a common procedure, but realize that it will still not completely
isolate replication - forced replication will still go through (i.e. in an out
of the 'schema mod' site). You may not do the forced replication yourself, but
if some other friendly administrator chooses to do so in order to
troubleshoot something else (e.g. via repadmin or replmon), your protection is
gone.
As such physical isolation is really your only option if you really want to
isolate a DC.
The Problem: you can't do all updates on a DC that's not connected to a network
(e.g. schema updates don't tend to work since it can't look up the schema
master, even if the role is held on the same machine etc.).
The Solution: there are many, but my favorite is simply to use VMs. You can
then add a couple of DCs as VMs on the same host and potentially move them to
your special site. You can then switch from bridged networking to host-only
networking so that these DCs are completely isolated from the network but can
still communicate between each other. This will allow you to test that these
will still replicate fine after the update. Once the tests have proven to work
fine, you can switch back to bridged networking and replicate the changes out.
Naturally, you can do the same with physical hardware and a separate network -
it's just so much easier using virtualization technologies.
/Guido
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, November 17, 2006 10:20 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] How to completely isolate a DC?
In the example of a schema mod, I tend to:
1. Move the schema master FSMO role holder DC to a 'schema mod' site
2. Change the replication schedule for all site links where this site
participates, so that replication is stopped in and out of the schema mod site
3. Make the schema change on the DC in the schema mod site
4. Test the change
5. Change replication schedules back so that the change propagates to other
sites
Obviously, you need to wrap some processes and procedures around the above but
you get the idea ... :)
neil
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Wang
Sent: 16 November 2006 20:20
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] How to completely isolate a DC?
I need to make a change across our domain. My plan is to make the change on one
DC and test it, then roll out to other 50 DCs.
I tried to temporarily disable outbound replication of Active Directory with
repadmin by doing this:
repadmin /options +DISABLE_OUTBOUND_REPL
To my surprise, the change I made still replicated to other DCs immediately.
So how can I isolate a DC and make sure the change I made not replicate to
other DCs?
Thanks for your help!
Andy
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] How to completely isolate a DC?
We're not talking about testing - this is about safe implementation. Prior to this everything should be tested in the lab - but a lab is never _exactly_ the same as production (unless you're a really small company or you have tons of money to keep the lab fully equal to your production environment). That's why even though you might have tested something successfully in a lab, you'll still want to implement it _safely_ in production. Especially for changes you can't undo easily (not saying that this effort is necessary for every single setting). Fully agree with not making un-trusted folks an admin - we're not talking about this. In large environments you'll still have more than one. And as sadly but truly communication between admins often lacks, I certainly prefer the safe route. It's all about protection in depth... /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Boaz Galil Sent: Friday, November 17, 2006 4:24 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] How to completely isolate a DC? Guido, 1.Friendly administrator - if you don't trust someone don't make him admin. 2. I really don't like your method, in my opinion changes should be tested on a separate network, test lab, some kind of environment that is similar to the production network but is separate from it. On 11/17/06, [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: All valid points indeed. I prefer to test changes in a lab first using prod like hardware (for obvious reasons). I therefore avoid the VM approach for those reasons. I prefer to implement a change freeze for the duration of any major changes. If a rogue / friendly admin makes a mod and disrupts the change then he/she will be looking on jobserve [or regional equivalent] within the next few hours :/ Your points are valid - I simply thought I'd express another way of attacking the same 'issue'. neil From: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Grillenmeier, Guido Sent: 17 November 2006 11:33 To: ActiveDir@mail.activedir.orgmailto:ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] How to completely isolate a DC? This is a common procedure, but realize that it will still not completely isolate replication - forced replication will still go through (i.e. in an out of the 'schema mod' site). You may not do the forced replication yourself, but if some other friendly administrator chooses to do so in order to troubleshoot something else ( e.g. via repadmin or replmon), your protection is gone. As such physical isolation is really your only option if you really want to isolate a DC. The Problem: you can't do all updates on a DC that's not connected to a network (e.g. schema updates don't tend to work since it can't look up the schema master, even if the role is held on the same machine etc.). The Solution: there are many, but my favorite is simply to use VMs. You can then add a couple of DCs as VMs on the same host and potentially move them to your special site. You can then switch from bridged networking to host-only networking so that these DCs are completely isolated from the network but can still communicate between each other. This will allow you to test that these will still replicate fine after the update. Once the tests have proven to work fine, you can switch back to bridged networking and replicate the changes out. Naturally, you can do the same with physical hardware and a separate network - it's just so much easier using virtualization technologies. /Guido From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Sent: Friday, November 17, 2006 10:20 AM To: ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] How to completely isolate a DC? In the example of a schema mod, I tend to: 1. Move the schema master FSMO role holder DC to a 'schema mod' site 2. Change the replication schedule for all site links where this site participates, so that replication is stopped in and out of the schema mod site 3. Make the schema change on the DC in the schema mod site 4. Test the change 5. Change replication schedules back so that the change propagates to other sites Obviously, you need to wrap some processes and procedures around the above but you get the idea ... :) neil From: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Andy Wang Sent: 16 November 2006 20:20 To: ActiveDir@mail.activedir.orgmailto:ActiveDir@mail.activedir.org Subject: [ActiveDir] How to completely isolate a DC? I need to make a change across our domain. My plan is to make the change on one DC and test it, then roll out to other
RE: [ActiveDir] Applying Permissions to 'cn=Schema' Container
I certainly support joes second solution: dont delegate this. As with some other suggestions described in the Delegation Guide (which overall is very useful), you shouldnt implement every role just because you can. Your AD infrastructure will not be in any danger if the Schema FSMO happens to be unavailable for a while. However, the likelihood for introducing danger to AD will grow if you delegate seizure of this role to someone who doesnt know what theyre doing the control of any FSMO role in your root domain should remain in the hands of the Enterprise Admins (lets just assume that they know what theyre doing, otherwise they shouldnt be EA either). /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, November 08, 2006 6:14 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Applying Permissions to 'cn=Schema' Container You have to modify the Schema container because the Schema FSMO is all about the Schema container. It is right and logical that you control who can do it by modifying permissions on it. Anothersolution would be don't delegate that. It isn't something that really shouldn't need to bemoved all that much anyway. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ivan Levendyan Sent: Wednesday, November 08, 2006 12:06 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Applying Permissions to 'cn=Schema' Container Hi All ! While reading Best Practices for Delegating Active Directory Administration (http://www.microsoft.com/downloads/details.aspx?familyid=631747a3-79e1-48fa-9730-dae7c0a1d6d3displaylang=en, http://www.microsoft.com/downloads/details.aspx?FamilyID=29dbae88-a216-45f9-9739-cb1fb22a0642DisplayLang=en) I can see that MSFT recommends using the following permissions while delegating 'Operation Master Roles Management': Seize the Schema Master Role WP on cn=Schema, cn=Configuration, dc=ForestRootDomain to modify the fSMORoleOwner attribute Extended Right Change-Schema-Master on cn=Schema, cn=Configuration, dc=ForestRootDomain The same thing (applying permissions to'cn=Schema') I can see in many other recommendations there. Why it is required to apply permissions directly to'cn=Schema' container and are thereany other solutions? Thanks, Ivan.
RE: [ActiveDir] OT for those in California
Nope, there weren't any updates on hypervisor during WinConnections - at least none I heard of. So this info is actually quite useful. Did they actually demo it at VMworld? Or just talk about it? Thanks Mark for sharing. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris Sent: Wednesday, November 08, 2006 1:49 PM To: ActiveDir.org Subject: Re: [ActiveDir] OT for those in California What I did manage to glean from MS was - that the virtualisation product will ship 180 days after longhorn does and will run on server core and full gui version. When the +180 server core ships it will be an update to the basic core version - rather than there being two flavours of core. All resources will be hot plug - disk, network, ram and cpu; but not hot unplugable. Oh and it will be free But that needs defining - you may need to sacrifice several goats to Rah though, to qualify. They were running 5735 for the sad ones out there, it will go to limited beta in two months and connect should have the details soon. Not sure about the mountain dew as the drink bins are always empty but, there are no queue's (lines) for the ladies - but that being said there are a fair few ladies here. Anyone got an update from WinConnections? Regards, Mark Parris Base IT Ltd Active Directory Consultancy Tel +44(0)7801 690596 -Original Message- From: Laura A. Robinson [EMAIL PROTECTED] Date: Wed, 08 Nov 2006 00:53:19 To:ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OT for those in California Okay, maybe my sense of humor is a little skewed. :-P -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laura A. Robinson Sent: Wednesday, November 08, 2006 12:48 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OT for those in California What's funny is that the blog entry doesn't say where Patrick is, either. That's why I commented. ;-) Laura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Wednesday, November 08, 2006 12:37 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] OT for those in California Blog post cut and paste http://blogs.technet.com/windowsserver/ I wasn't there.. Mark was at VMworld as well as Patrick If I had been there I would have blogged about the lack of line for the women's restroom, whether or not Mountain Dew was readily available and what not... ;-) Now I did google for the PGE links Laura A. Robinson wrote: Susan, two questions- 1. Why are you now going by Patrick? 2. Do you plan to identify the event of which you write below for those who may not know? :-) Laura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Tuesday, November 07, 2006 10:12 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] OT for those in California http://blogs.technet.com/windowsserver/archive/2006/11/07/LA-T raffic-_2D00_-1_2C00_500-Shirts-in-150-minutes.aspx The show floor proved to be really busy this morning. One piece of evidence: we distributed 1,500 shirts in 2.5 hours. The orange shirts say Virtualize World Peace and the crowd was 2-deep at demos for Virtual Machine Manager (in beta now), SoftGrid and Windows Server virtualization (the hypervisor-based architecture for Longhorn). The sessions have proved to be muc better than the keynote. A few sessions on VDI and some interesting insights on how that model can create even more power consumption than before and the scalability challenge of adding all those desktop images to the servers/blades. The power consumption challenge was perhaps the most interesting given the comments from PGE earlier today in the keynote. PGE, which provides power to most of California, is providing business with credits ($700-$1,300) for consolidating servers in the datacenter using server virtualization. More to come later. Patrick -- Tax credits... interesting. and excuse me us SBSers have been been putting 5 servers and the kitchen sink service on one box for years and I've not gotten a dime from PGE and I'm a shareholder snort ;-) http://searchservervirtualization.techtarget.com/originalConte nt/0,289142,sid94_gci1226458,00.html High Tech and Healthcare Program: http://www.pge.com/biz/rebates/hightech/ http://www.pge.com/docs/word_xls/biz/rebates/2006_Incentive_Ap p/2006%20PGE%20app%20forms.xls -- Letting your vendors set your risk analysis these days? http://www.threatcode.com If you are a SBSer and you don't subscribe to the SBS Blog... man ... I will hunt you
RE: [ActiveDir] OT: M$
Ah - now I see - that must be their back-door to access every system Windows is running on ;-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Lefkovics Sent: Friday, November 10, 2006 9:36 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OT: M$ What does all this have to do with the hidden administrative share on the M: drive? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laura E. Hunter Sent: Thursday, November 09, 2006 6:17 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] OT: M$ You're not a fake employee, I've seen you. :-) BrettSh, too. It's that Stuart Kwan guy whose existence I'm doubting. (Come on, was that enough to inspire the rarity that is a Stuart Kwan ActiveDir post? Please? PLEASE?!?!?!?!?!?!?!?!?!?!? ;-)) On 11/9/06, Eric Fleischman [EMAIL PROTECTED] wrote: Not that I really care if people say M$ or not, but I thought I'd comment on one thing, in the name of full disclosure.. My participation on this list has __nothing__ to do with money. I don't get compensated on any level for this. Heck, I don't even work on AD anymore, so this is like 2 degrees of separation away from anything that MS compensates me for. So, is MS out to make $? Sure. Is AD part of that money-making strategy? Sure. Does that have anything to do with MS employee participation on this list? I don't think so. Others (at least those that I can recall posting here as I type this mail) on this list fall in to the same boat. A couple of them don't work on AD anymore either. Why do I hang out here? I do it because I care about customers and about AD/ADAM. It has nothing to do with my salary. It's also why I still blog about AD, answer newsgroup questions, answer internal questions (DLs, PSS, MCS, other PGs, etc.), handle direct emails from a myriad of non-MS people (some I know, some are totally out of the blue), fix code for people that ask for help, etc. I don't get paid for any of this. ~Eric Borg #145719302 Insert conspiracy theory here about how this whole mail is a lie and the man actually wrote it on behalf of the fake employee that goes by Eric Fleischman List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/
RE: [ActiveDir] Change default User-Account-Control behavior
Well, the tabs and even the user account creation dialog in AD can be extended, it's just not an easy task to do for the normal administrator. Some dev-work with c-programming would be involved. I'm not aware of mechanisms to extend the UI or dialogs for local accounts. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Schofield Sent: Thursday, November 02, 2006 7:29 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Change default User-Account-Control behavior Thanks Joe for the verification. I couldn't find anything but figured if anyone knew if it could be done. They would be on this list. :) Steve Schofield Windows Server MVP - IIS ASPInsider Member - MCP http://www.orcsweb.com/ Managed Complex Hosting #1 in Service and Support - Original Message - From: joe [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Wednesday, November 01, 2006 5:58 PM Subject: RE: [ActiveDir] Change default User-Account-Control behavior Nope. Scripts, batch files, and custom tools for you. :) -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Schofield Sent: Tuesday, October 31, 2006 2:38 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Change default User-Account-Control behavior Is it possible to change the default behavior when creating local or AD user accounts? I would like to set certain options when creating accounts using normal tools without having to write a script. Any tips / advice is certainly appreciated. Steve Schofield List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/
RE: [ActiveDir] sysvol replication
Yes, not only for Win2k, but also for Win2k3 (won't change until you deploy Longhorn and switch to LH DFL) /Guido --- sent wirelessly using iPAQ 6900 -Original Message- From: Graham Turner [EMAIL PROTECTED] To: activedir@mail.activedir.org activedir@mail.activedir.org Sent: 10/19/06 5:29 PM Subject: [ActiveDir] sysvol replication Just a quick query on sysvol replication we have put in place strategy for delegation of directory shared as netlogon by way of adding an ACE to the NTFS permissions is it correct that on DC's running Windows 2000 SP4 that a change in the NTFS permissions will generate the change notifications such that the NTFS permission change is replicated to all DC's ?? in terms of schedule for sysvol does it use the schedule as determined by site link configuration ?? Thanks List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] sysvol replication
my reply was a little hurried - so what I meant was that in 2k/2k3 the NTFS permission/ACL changes will actually trigger a full replication of all files and folders that have been affected by the change of permissions (i.e. when the changes are applied at the top level, all files will be replicated). This is due to a limitation in the current version of FRS which always replicates the whole file for any change that happens to the files (and an ACL change is just seen as any other change). In Longhorn, once Domain Functional Level is reached (i.e. all DCs in a domain run Longhorn Server and the switch to DFL 3 has been made), the DCs will switch to leveraging the new DFSR replication mechanism (which is basically what was made available with Win2003 R2). This is a very efficient for replicating files as it only replicates the actual changes - incl. ACEs. and yes the SYSVOL replication follows your site-link schedules - however, since Win2k3 SP1 (and Win2k SP4) you can also (finally) trigger it manually via the NTFRSUTL tool. Also I've seen ocations where SYSVOL actually replicated outside the site-link schedule window - can't tell you right now under which circumstances this is the case. /Guido From: [EMAIL PROTECTED] on behalf of Almeida Pinto, Jorge de Sent: Thu 10/19/2006 8:24 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] sysvol replication won't change until you deploy Longhorn and switch to LH DFL Guido, can you explain what you mean with this? (I know SYSVOL will be replicated with DFSR as soon as DFL=W2K7 is reached) thanks jorge Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto Senior Infrastructure Consultant MVP Windows Server - Directory Services LogicaCMG Nederland B.V. (BU RTINC Eindhoven) ( Tel : +31-(0)40-29.57.777 ( Mobile : +31-(0)6-26.26.62.80 * E-mail : see sender address From: [EMAIL PROTECTED] on behalf of Grillenmeier, Guido Sent: Thu 2006-10-19 19:25 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] sysvol replication Yes, not only for Win2k, but also for Win2k3 (won't change until you deploy Longhorn and switch to LH DFL) /Guido --- sent wirelessly using iPAQ 6900 -Original Message- From: Graham Turner [EMAIL PROTECTED] To: activedir@mail.activedir.org activedir@mail.activedir.org Sent: 10/19/06 5:29 PM Subject: [ActiveDir] sysvol replication Just a quick query on sysvol replication we have put in place strategy for delegation of directory shared as netlogon by way of adding an ACE to the NTFS permissions is it correct that on DC's running Windows 2000 SP4 that a change in the NTFS permissions will generate the change notifications such that the NTFS permission change is replicated to all DC's ?? in terms of schedule for sysvol does it use the schedule as determined by site link configuration ?? Thanks List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/
RE: [ActiveDir] OT: File Server Permissions Design Question
ABE won't necessarily reduce the number of groups you need to control access, although it certainly controls the visibility for those that don't have any rights to specific data in your shares. Your approach is a very common approach and certainly nothing unusual. Not sure how you get from 15 departments to 60 groups (a more concrete sample of your group structure would help understand). But whatever it is, a user will likely be a member of quite a few groups either directly or through nesting - I wouldn't worry too much about the number of groups you create (if they have good structure that makes sense), but more about the number of groups a user will have to be a member of. At some point you have to think about the kerb token size the users will get at logon and if that is going to cause issues. You can obviously influence this by choosing to create some of your groups locally on the FS, but this has it's own downsides. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Evans Sent: Thursday, October 12, 2006 1:20 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OT: File Server Permissions Design Question We're actually using ABE (or will be once we start migrating to this box). It helped me a ton with a couple situations (home folders being the big one because of something called FERPA, if you don't know what it is you don't ever want to know). However I don't see how that helps me here specifically. Steve Evans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris Sent: Wednesday, October 11, 2006 2:38 PM To: ActiveDir.org Subject: Re: [ActiveDir] OT: File Server Permissions Design Question Have you looked at installing the Access based Enumeration feature pack and basing the permissioning on this type of model? Assuming W2003. Regards, Mark Parris Base IT Ltd Active Directory Consultancy Tel +44(0)7801 690596 -Original Message- From: Steve Evans [EMAIL PROTECTED] Date: Wed, 11 Oct 2006 12:57:52 To:ActiveDir@mail.activedir.org Subject: [ActiveDir] OT: File Server Permissions Design Question I've had difficulty finding a better forum in which to ask this. And since it involves AD Security Groups I thought I could get away with it. We're in the process of migrating to a new file server. Our shared drive has a basic structure of: Shared\Department\Sub-Department\one public folder one private folder Our original thought was to have one Read and one Read/Write group for each public and private folder. Those groups would then be populated by role based groups (department groups, position groups (ex all management)). I've written a script that you can point to a directory structure and it creates the appropriate groups and assigns the security permissions. However I end up creating a lot of groups. Just in ITS (for example) we have 15 sub-departments so that will produce 60 groups right there. On the other hand everything is very structured and in theory you can mange file security permissions from within AD. Since everything is scripted you never need to go and look at folder permissions (except for the file server admin guys when troubleshooting). I'm also concerned that users will end up being in groups that are nested in a substantial number of groups. For instance most of the public-read groups for ITS will contain the group ITS - All Staff. That means any given ITS employee will have 30 security group tokens just from this. Any thoughts or opinions? Steve Evans 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 [EMAIL PROTECTED]) List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Forest trust divestitures
I didnt read Harveys comment ForestB DCs are physically landed at various Company A locations in pocket networks that can talk back as something that already exists today. I would have thought is part of his plan and that today there are no DCs from Company B in any of Company A locations. So were using different assumptions in our discussion Harvey, can you clarify? Also note Jorges very valid comment on responsibility: the interims forest C has a clear hand-over of responsibility of the BU being divested. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Wednesday, October 11, 2006 3:12 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Forest trust divestitures Agreed that the risk is there. Good idea to spell it out, but I got the sense that much gnashing of teeth was already had over the decision to create a one-way trust or not. And because the dc's already share a network (even though firewalled from time to time) I'm not seeing how the forest C topology helps to mitigate the risk you describe? They'll still have possession of a DC from a previously trusted (and therefore suspect) forest. No difference there. Unless Forest A keeps control of the demilitarized forest C. But then how does Forest B learn to trust them? :) In any event, I see a double migration without much mitigation of risk nor benefit. I'm guessing I'm missing something in the description of the problem else not asking the right question(s). I'm curious if that's the case? If so, is there more information to be aware of in this scenario that can be shared? On 10/10/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: Al, what risk has been assumed? You're assuming everyone understands all the potential risks of binding two AD infrastructures together as suggested, and that we're all playing nice to another? I'm not assuming that. I'm always assuming that there is potential for the bad guys to be around. And if they are, the original plan allows the wrong people (read: Admins of Domain A) to have access to DCs of Domain B. And potentially also the other way around. Not good. Unless merger and we're talking the same company but that's not the case here these are two different companies. A firewall doesn't protect from a compromised DC, especially if you bring that DC back into your production forest /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al Mulnick Sent: Tuesday, October 10, 2006 11:44 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Forest trust divestitures curious. I'm not seeing the same things as Guido here. PDC/RID will remain on the forest, but it will be blocked for the duration of the migration while A forest and B forest are not firewalled in that one site. (as I read it). But what makes me curious is this: The risk has already been assumed. What is the advantage here of adding forest C? I see that it's extra steps, but I don't see the connection to the drawn out go-at-your-own-pace migration. I'm interested in having it spelled out for me though. Please. :) On 10/10/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote: I certainly wouldn't allow it if I were security either, but they said it was okay. Probably has something to do with the fact the acquisition will almost double the size of the company :). The interim forest is a great idea. I had intended to bring up a test forest to dry-run the migration in company A environment, but I didn't follow the train of thought through to suggest that the actual migration be done to that forest, and moved to the target company. On 10/10/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: If I were the security officer for Company B, I would have real issues with this plan. Most companies with sufficient understanding of AD Security would not want any of their DCs placed in any location where the other company's network is still active (i.e. DCs from company A and company B on same network). That's different in a merger, where the full IT infrastructure will be merged anyways. But you're talking about a divestiture of a PART of a company. The plan you're describing doesn't really scale well over time not sure if you're considering issues you're experiencing during the migration how long are you willing to run forest B without PDC/RID etc? What I've done in similar situations is to implement an interims forest. Step 1: implement Interims Forest C in Company A's network migrate objects and resources from divested BU over from Forest A to C. Test that the divested BU works in Forest C and that other Company A Bus continue to work fine as well. Potentially change naming convention of objects to that of Company B during the migration to Forest C. Troubleshoot as necessary
RE: [ActiveDir] Forest trust divestitures
If I were the security officer for Company B, I would have real issues with this plan. Most companies with sufficient understanding of AD Security would not want any of their DCs placed in any location where the other companys network is still active (i.e. DCs from company A and company B on same network). Thats different in a merger, where the full IT infrastructure will be merged anyways. But youre talking about a divestiture of a PART of a company. The plan youre describing doesnt really scale well over time not sure if youre considering issues youre experiencing during the migration how long are you willing to run forest B without PDC/RID etc? What Ive done in similar situations is to implement an interims forest. Step 1: implement Interims Forest C in Company As network migrate objects and resources from divested BU over from Forest A to C. Test that the divested BU works in Forest C and that other Company A Bus continue to work fine as well. Potentially change naming convention of objects to that of Company B during the migration to Forest C. Troubleshoot as necessary. Step2: when ready separate network of Forest C from Company A and integrated it with network from Company B Step3: with sufficient time for planning the integration, migrate objects and resources from Forest C to B. If not done previously, adjust naming of objects convention during this migration. This sounds like a whole lot of extra work, but usually it pays off: it is the most secure way to separate the divested part of the company and doesnt put either company at (unwanted) risks. It also gives you more flexibility on when to do which step and wont cause any issues with either of the operational forests. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harvey Kamangwitz Sent: Monday, October 09, 2006 7:58 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Forest trust divestitures Hi all, I'm consulting on a divestiture, and naturally the companies want their respective AD forests to have the minimum amount of contact necessary to migrate the security principals in the divestiture from company A to company B. I wanted to sanity check with this brain trust that we can do a one-wayforest trust in this firewalled situation. (They're going to use Quest Migration Manager for AD, and though technically it doesn't REQUIRE a one-way trust, the Quest SE says it's an order of magnitude easier. A one-way outgoing trust has been approved by the various security players so it can be done.) - ForestA (multiple domains) and ForestB (single domain). In the beginning, no communication between them. - ForestB DCs are physically landed at various Company A locations in pocket networks that can talk back to Company B, so they're healthy.Though they're at Company A, they are firewalled from A until D-day. All forest B pocket network DCs can talk to each other as well as back home. D-Day: - Transfer PDC and RID FSMOs toone of company B'spocket network DCs. (see next step for why.) - Firewall off communication to company B's network, and open up comm to company A's network. This will make for a temporarily unhappy company B forest, but it will be okay for the duration of the migration. More importantly, it'll make the PDC available on the company A network for the forest trust setup and the RID master also available to hand out more RIDs during the migration. There should now be a functional company B forest on company A's network (though it'll be complaining about missing DCs). - Configure DNS conditional forwarding in forest A to find forest B's pocket network DCs and vice versa. Would I have to set up forwarding on every DNS server in forestA? They have a lot of DCs. - Establish the forest trust from A to B. Would selective authentication on the trust protect the visibility of A's security principals? It's mainly designed to protect B's resources from A's users, isn't it? - Do the migration. - Remove the trust - Flip the pocket network firewalls back to block network A and allow network B. - Let replication settle down, then transfer FSMOs back to their original locations. - misc cleanup, like removing conditional forwarding Appreciate any fine-tuning of this scenario, thanks!
RE: [ActiveDir] Forest trust divestitures
Al, what risk has been assumed? Youre assuming everyone understands all the potential risks of binding two AD infrastructures together as suggested, and that were all playing nice to another? Im not assuming that. Im always assuming that there is potential for the bad guys to be around. And if they are, the original plan allows the wrong people (read: Admins of Domain A) to have access to DCs of Domain B. And potentially also the other way around. Not good. Unless merger and were talking the same company but thats not the case here these are two different companies. A firewall doesnt protect from a compromised DC, especially if you bring that DC back into your production forest /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Tuesday, October 10, 2006 11:44 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Forest trust divestitures curious. I'm not seeing the same things as Guido here. PDC/RID will remain on the forest, but it will be blocked for the duration of the migration while A forest and B forest are not firewalled in that one site. (as I read it). But what makes me curious is this: The risk has already been assumed. What is the advantage here of adding forest C? I see that it's extra steps, but I don't see the connection to the drawn out go-at-your-own-pace migration. I'm interested in having it spelled out for me though. Please. :) On 10/10/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote: I certainly wouldn't allow it if I were security either, but they said it was okay. Probably has something to do with the fact the acquisition will almost double the size of the company :). The interim forest is a great idea. I had intended to bring up a test forest to dry-run the migration in company A environment, but I didn't follow the train of thought through to suggest that the actual migration be done to that forest, and moved to the target company. On 10/10/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: If I were the security officer for Company B, I would have real issues with this plan. Most companies with sufficient understanding of AD Security would not want any of their DCs placed in any location where the other company's network is still active (i.e. DCs from company A and company B on same network). That's different in a merger, where the full IT infrastructure will be merged anyways. But you're talking about a divestiture of a PART of a company. The plan you're describing doesn't really scale well over time not sure if you're considering issues you're experiencing during the migration how long are you willing to run forest B without PDC/RID etc? What I've done in similar situations is to implement an interims forest. Step 1: implement Interims Forest C in Company A's network migrate objects and resources from divested BU over from Forest A to C. Test that the divested BU works in Forest C and that other Company A Bus continue to work fine as well. Potentially change naming convention of objects to that of Company B during the migration to Forest C. Troubleshoot as necessary. Step2: when ready separate network of Forest C from Company A and integrated it with network from Company B Step3: with sufficient time for planning the integration, migrate objects and resources from Forest C to B. If not done previously, adjust naming of objects convention during this migration. This sounds like a whole lot of extra work, but usually it pays off: it is the most secure way to separate the divested part of the company and doesn't put either company at (unwanted) risks. It also gives you more flexibility on when to do which step and won't cause any issues with either of the operational forests. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Harvey Kamangwitz Sent: Monday, October 09, 2006 7:58 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Forest trust divestitures Hi all, I'm consulting on a divestiture, and naturally the companies want their respective AD forests to have the minimum amount of contact necessary to migrate the security principals in the divestiture from company A to company B. I wanted to sanity check with this brain trust that we can do a one-wayforest trust in this firewalled situation. (They're going to use Quest Migration Manager for AD, and though technically it doesn't REQUIRE a one-way trust, the Quest SE says it's an order of magnitude easier. A one-way outgoing trust has been approved by the various security players so it can be done.) - ForestA (multiple domains) and ForestB (single domain). In the beginning, no communication between them. - ForestB DCs are physically landed at various Company A locations in pocket networks that can talk back to Company B, so they're healthy.Though they're
RE: [ActiveDir] OT: wikis
So, where would the ant be 5 seconds after the box started to tumble, assuming it walks at 1 inch per hour (really slow ant). I'd really like to know :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Tuesday, October 10, 2006 11:41 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OT: wikis And also, IMO, to help people realize they should question established thought patterns. I found it interesting that you teach math to children yet you don't get enough math until pretty well into university that you can understand how it actually works. Mostly though I found the story problems fun, like when you have to build an equation that will give you the point in space at any given point in time where an ant is if he is walking towards the center of a 78 RPM record at x inches per hour that is in a box that is tumbling at some fixed interval falling off the edge of the grand canyon. Completely worthless in terms useful info but a great mental exercise type problem. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Cornetet Sent: Monday, October 09, 2006 10:05 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OT: wikis They like it because it shows that division by zero can bite you without being obvious. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond Sent: Sunday, October 08, 2006 4:41 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OT: wikis I've seen that stunt a few times. I'm not sure the point of showing it but math teachers love to demonstrate it for some reason. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 -Original Message- From: [EMAIL PROTECTED] [mailto:ActiveDir- [EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, October 05, 2006 2:22 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OT: wikis Careful, I recall a math professor in my differential equations class or maybe it was higher throwing a proof up on the board showing that 1 + 1 != 2 and it wasn't a numberical base trick I didn't follow through it, I just closed my eyes and shook my head and thought forward to my communications class as the sights were easier on the eyes... I still wonder why I went into a field with such a high ratio of men to women... :) -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laura A. Robinson Sent: Thursday, October 05, 2006 12:55 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OT: wikis 999,998 + 2 = 1,000,000, not 100,000. ;-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Nims Sent: Thursday, October 05, 2006 11:49 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] OT: wikis It's funny how we quote wikis as definitive sources of information, when they can be edited by anyone and everyone :) Who vets the edits and how much does that person know about the subject matter?? Anyone can edit, which is why they are generally correct. When 100,000 people view a record, and 2 people want to change it to be incorrect, 999,998 will want to correct it. I wouldn't use a wiki as a great historical or technical source. But for encyclopedia entries, which give a good summation of a subject, they are great. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] what is the meaning of OT in front of the subject
While this thread is OT, I'd actually consider your example to be right on-topic ;-) /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris Sent: Thursday, October 05, 2006 4:28 PM To: ActiveDir.org Subject: Re: [ActiveDir] what is the meaning of OT in front of the subject Off Topic i.e. the people on the list might know the answer but it's nothing to do with Active Directory. e.g. What are the recommended Anti-Virus exclusions for a Domain Controller? Mark Mark Parris Base IT Ltd Active Directory Consultancy Tel +44(0)7801 690596 -Original Message- From: Ramon Linan [EMAIL PROTECTED] Date: Thu, 5 Oct 2006 09:39:38 To:ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] what is the meaning of OT in front of the subject Some of the subjects have that OT preceding the subject, what's that? Thanks List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Single forest with two domain trees to splut up.
The DomainB that you want to split off still needs the root domain (DomainA) to work. So you can't just say screw DomainA and cut it off. You'll need at least 1 (2 for redundancy) DCs of DomainA to remain in the site you wish to split off. No problems to get rid of DomainB in the site that keeps DomainA. There are still multiple risks with this approach as you don't need direct connectivity for the folks in Site2 (DomainB) to do harm to your folks in Site1 (DomainA) - they still have the same Enterprise Admins and local Admins SID in the root domain and you can do a lot of things with a notebook that travels between these sites... So ideally (and really the only way to do it safely from a security standpoint) you're talking about a migration of your DomainB objects to a new forest. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of knighTslayer Sent: Wednesday, October 04, 2006 11:10 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Single forest with two domain trees to splut up. Hello, This is my first post, so please forgive me if this question has already been asked... I have a mixed AD forest with two domain trees. Each domain tree is located at a different geographical site, and sites and services is configured to reflect this. DomainA has the namespace of 'logistics.ads' and DomainB has a namespace of 'finance.dom' The very first domain tree (DomainA) is a Windows 2000 domain and the second domain tree (DomainB) is a Windows 2003 domain. Finance.dom has been bought by a third party and I must split the forest in two and resolve any issues that arises from doing this. As logistics.ads was the first domain in the forest, it holds the Schema Master role and Domain naming master role. Exchange 2000 is installed at DomainA and Exchange 2003 is installed in DomainB. Administrative groups are used to reflect the geographical topology of my set-up. Each domain has its own SMTP namespace and SMTP routing will not be a problem as I can comfortably overcome this. The GAL being split and replaced with contacts is acceptable and I have no issues at this level. The WAN connection between the domains will be removed and the only means of communication between the two organisations will be through SMTP routing through the internet and nothing else. No other application between the domains are in use, besides Exchange. My current plan is to simply cut the link between the sites and seize the roles that are missing from the newly split domains - so in effect bringing up two forests. Issues with Exchange, ghosted servers in AD, and so on will be removed using ADSI edit and NTDSutil. My main question is this: is there better technique I should follow for splitting up a forest or am I on the right track? Thanks in advance René List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Forest trusts
It will, but it is a solvable problem. You'll also have some headaches for the trust itself, but that's where the nifty Win2003 features such as Name Suffix Routing and Top Level Name Restrictions come into play. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Gilbert Sent: Tuesday, October 03, 2006 4:32 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Forest trusts Don't you have to do some DNS delegations to ensure clients in one forest can find clients in the other forest? I would think that having domain.com as the tier two for both forests will cause some unique DNS headaches. Dan Original Message Subject: RE: [ActiveDir] Forest trusts From: Almeida Pinto, Jorge de [EMAIL PROTECTED] Date: Tue, October 03, 2006 6:47 am To: ActiveDir@mail.activedir.org Both forests can be connected to each other as long as within the connected environment each domain name is unique (NetBIOS and DNS)... So if you have a forest called DOMAIN.COM (NetBIOS = DOMAIN) and another forest called SUB.DOMAIN.COM (NetBIOS = SUB) you can connect them to each and setup trusts between the forests. jorge -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lev Zdenek Sent: Tuesday, October 03, 2006 15:35 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Forest trusts Hello evr. I have two independent forests. Is it possible to trust forests which share a same name space. For example. I have domain in first forest domain.com and a domain in second forest my.domain.com. If not is it possible to migrate with some tools a domain my.domain.com to domain domain.com ? Thx Zdenek Lev 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 This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] forest disaster recovery plan.
Microsoft is working on an updated Forest Recovery guide for Windows Server 2003, however, the basic procedures for full forest recovery are still the same as youd have to do for a Windows 2000 AD forest. And for the later a guide already exists: http://www.microsoft.com/downloads/details.aspx?displaylang=enFamilyID=3EDA5A79-C99B-4DF9-823C-933FEBA08CFE Naturally, Win2003 offers new features such as Install from Media to speed up promotion of DCs, but the general gist of a full recovery of a multi-domain AD forest remains as complex as described in the Microsoft document just referenced above. Realize that there are different aspects to AD recovery and Forest Disaster Recovery is obviously for that very rare and unlikely occasion (that you still need to be prepared for). To get a good overview about the other challenges involved in AD recovery (especially in a multi domain forest), you should have a look at the following whitepapers: · A Definite Guide to Active Directory Disaster Recovery (from NetPro HP) http://www.netpro.com/media/pdf/NetPro_ADDR_Guide.pdf · 11 Things to Know about Active Directory Recovery (from Quest HP) http://www.quest.com/documents/list.aspx?searchoff=truecontenttypeid=1prodfamily=13 /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yann Sent: Tuesday, September 26, 2006 7:02 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] forest disaster recovery plan. Hello all, I have to write a forest disaster reocvery plan fonr my entrerprise, and also test this plan in a test lab. We have AD 2k3 forestin FFL mode with: - one empty root : no resources, only for security reason (to secure Entreprise Ad domain admin). - 3 childs domain. - each DCs haveAD integrated dns zone. - Wins are also part of the infrastructure. - 20 AD sites. I don't know where ihave to start. Is there a roadmap or a step-by-step guide that describes the different strategies of a good recovery ? And ifexperts in this list have good advices, they are welcome :) Thank you very muche, Yann Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. Cliquez ici.
RE: [ActiveDir] How are folks setting hidden user attribs?
Common question its fairly difficult to extend ADUC with a new tab that allows you to edit the attributes you want, but its fairly easy to add a context menu (e.g. when right-clicking on a user account) to start a script that would pop up a dialog box and allows to enter the appropriate data for the object. The latter is done by displayspecifiers. More info found here: http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/howto/adschema.mspx /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Fontana Sent: Thursday, September 21, 2006 9:04 AM To: ActiveDir@mail.activedir.org Subject: How are folks setting hidden user attribs? Hey guys, Im curious how people are populating attributes such as employeeid, employeetype, etc, specifically when creating\modifying accounts using the GUI (ADUC)? Besides me writing something to populate the fields what other resources do I have to allow other selected users (account creators) to populate these fields? TIA -alex
RE: [ActiveDir] Elevating privileges from DA to EA
Not commenting on the elevation of rights strategies - should be clear by now that it is simple once you know what you're doing (and Google will help you and your enemy) But a quick comment on using domains as a replication boundary due to the following statement: Replication wise, the Global Catalgue is a fraction the size of the full database While I agree it may still make sense to have a separate domain to control replication, if you make the DCs a GC, they will certainly replicate much more than a fraction of the size of the full db = from past experience comparing DIT sizes, they will replicate approx. 70% of the data from all other domains in the forest. That's still a lot of data on a GC - so if the domain with 90.000 users has a DIT of approx. 5 GB, a GC in the Alaska domain would likely still be 3.5 GB in size, while a DC would hardly be more than 40 MB. The more important point is, that most of the data in the GC is fairly static, so that it shouldn't cause too much replication traffic. And if the same guys manage that manage your main domain also manage the Alaska domain (and no one else gets domain admin rights in the Alaska domain), you're not really increasing your attack surface either. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, September 15, 2006 7:15 PM To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Elevating privileges from DA to EA Hi All I wanted to weigh in with two comments. 1) Elevating priveledges from DA to EA (or from physical DC access to EA) is simple - it takes about 45 minutes and unless you have some very good active monitoring is difficult to detect. There are automated tools out there for doing this. I have been known to use the term lazy EAs to refer to domain admins. 2) Replication boundaries is another reason for separate domains. a million objects can lead to huge DITs and very slow replication - especially in a build a new DC case. Separating that into multiple domains - to put smaller load on locations where bandwidth is an issue is worth considering. For example. 90,000 users. 200 of those are in Alaska The rest of the world has good bandwidth, Alaska locations all have the equivalent of 56K modem speed. DIT and Sysvol size is about 7G, but for Alaska users there are only 3 GPOs that affect them Rather then doing 1 domain I can put the 200 Alaska users in their own domain. Security wise, there is no advantage. Replication wise, the Global Catalgue is a fraction the size of the full database, the Sysvol never replicates anywhere in Alaska,and replicaiton for that domain will cause less strain on their bandwidth - 200 users will create a much lower amount of changes then 90,000 users. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service 202-230-2983 [EMAIL PROTECTED] Al Mulnick [EMAIL PROTECTED] om To Sent by: ActiveDir@mail.activedir.org [EMAIL PROTECTED] cc ail.activedir.org Subject Re: [ActiveDir] Elevating 09/15/2006 11:34 privileges from DA to EA AM AST Please respond to [EMAIL PROTECTED] tivedir.org I agree and add to that some additional thoughts: Not long ago there was some conversation around a suggestion that [EMAIL PROTECTED] put out regarding the idea of using multiple forests vs. domains in such a model. Personally, I disagree with that recommendation as given. I think A LOT more additional information is required before saying that, but I digress. If you decide to use the multi-domain model, I have to assume that you either have different password policies or a strong layer-8 contingent driving things. If the latter, I hate it for you. If you have a requirement to separate the domains from the forest, your workload just went through the roof, and with that your costs. Was it me I'd want to learn from my past mistakes ;0) and approach this by reversing the conversation. By that I mean I'd want each potential domain owner to absolutely and in a detailed manner specify the functions they need to execute. From there, we'll encompass the rights needed for each of those functions. I think what you'll find is that you can do almost all of it with a single domain if different password policies are not needed (mostly, but you know all of that anyway). From there, I'd be sure to spell all of that out the project sponsor because the costs (both ongoing and up front) can be significant. The amount of complexity and issues with other directory based applications alone can be enough to put them off and actually follow a recommendation such as this. The push
RE: [ActiveDir] OT: WinRE
Well, it will basically sit in between everything - you boot into this environment and then you're able to restore your OS or parts of it, including AD. The whole backup mechanism has been rewritten in LH and WinRe is the environment used for recovery. Unsure at this time, if you'll actually be able to restore AD using what's currently known as the DS Restore Mode. But they are still working on this so many things still in the open. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris Sent: Monday, September 18, 2006 5:12 PM To: ActiveDir.org Subject: [ActiveDir] OT: WinRE Not too sure where this WinRE will sit with Windows Server and Active Directory, but anyway. http://blogs.msdn.com/winre/archive/2006/09/18/760295.aspx Regards Mark Parris Base IT Ltd Active Directory Consultancy Tel +44(0)7801 690596 List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Handling different schemas - managing maintaining updates
The AD schema analyzer is quite useful for comparing schemas to find missing attributes and classes (and to export them to LDIF so as to allow an import to the target schema). Note however, that it doesn’t find differences at the level of properties you have set for your schema objects, for example it doesn’t find the difference in the searchFlags for an attribute that exists in both schemas. As such you need to know how close you want your schema to match and likely need to an exact compare either using custom scripts or LDIF dumps of the complete schema coupled with text-compare tools. In general I would want to question what your goal is – like Al I am assuming you want to make the schema more manageable. Basically a convenience so you don’t have to worry about managing and documenting the differences. That’s quite different from a technical necessity, where you may need to fully replicate all objects in your AD along with all attributes (except the ones managed by the system) – in this case, you may need to keep your schemas fully in sync. I would not much discuss the security with respect to the Schema classes and attributes stored in the different Forest schemas – I would not say that there is much of a risk in knowing you have XYZ attributes defined in either schema. The discussion is much more relevant as to which data do you plan to replicate between the two? Let’s assume you are storing sensitive data in one of your forests, for example, you may store the social security number of your employees in a company specific attribute called “MyCompany-Employee-SSN”, and you have even done everything to hide this data from normal read access (i.e. you’ve configured it as a confidential attribute). Do you want this data to be replicated to the other forests? If not, then I would also not suggest to add the special schema attribute to your other forests schema, since this way you hinder it from being synced by accident (not saying you couldn’t sync it elsewhere). If later there is a necessity to replicate the data across to the other forest(s) you could add a simple procedure in your ITIL processes that would ensure that the target schemas need to be updated appropriately prior to replicating the data. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Thursday, September 14, 2006 3:29 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Handling different schemas - managing maintaining updates Yep, the schema analyzer would be a good tool to have hold of. I have to ask though: is the goal to make this mish-mosh manageable by making it all the same (i.e. cookie-cutter?) Or is there some other goal you're describing? I'm assuming that you want it to be the same across the enterprise to make it more manageable. Often this is done so that a central team to can control it and /or so that people can implement workable IdM systems. Realistically, such a system cannot be implemented without some known similarities so it makes sense. I don't see any particular security related issues with schema entries unless your schema gives away company secrets of some sort. It's just a holder for the most part, and it's the data/information that it contains that would be of value. Knowing that it may exist is of lesser value, but is a risk that must be addressed. ITIL? Nice to have. Of course the term, trust, but verify keeps ringing in my head but it's still nice to have such a process in use. Al On 9/13/06, Joe Kaplan [EMAIL PROTECTED] wrote: I like this advice as well.In terms of some of the nuts and bolts of how one might do this, as a software guy, I'm a huge proponent of source code control/configuration management systems and simple, text-based file formats for the stuff you stick in your source repository.As such,I believe LDIF files are the one true way to maintain your custom schema stuff. The ADSchemaAnalyzer (usually associated with ADAM) is probably a useful tool for doing a lot of the compare and extract work here. Joe K. - Original Message - From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Wednesday, September 13, 2006 8:37 AM Subject: RE: [ActiveDir] Handling different schemas - managing maintaining updates Without wishing to appear facetious :) - I would suggest if the company follows ITIL practices then they already have a change mgmt and config mgmt process and/or system which helps achieve your goal. As far as best practices are concerned, I would aim for a 'core' schema config which is present in all instances of ADAM or AD schemas but manage differences via the ITIL framework (mentioned above). neil List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive:
RE: [ActiveDir] Isolating a DC
Agree, isolating by site is often confused with requiring a separate subnet and thus extra efforts on the networking infrastructure. Thats actually not the case. You can create your AD site and just assign it a 32bit masked IP address as the subnet if the other sites are properly configured, this will ensure that no client will try to leverage the DC in this special site. Realize that a separate site doesnt take care of the generic DC lookups performed by clients (e.g. when they join the domain or when all DCs in their site fail) however, adjusting the priorities in DNS and configuring the DNS mnemonics appropriately for the DC in the special site will also take care of this extra challenge (should be described in the Exchange Server Site doc for which Brian previously provided the link). /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Hargraves Sent: Wednesday, September 13, 2006 8:26 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Isolating a DC Yeah, I didn't mean to sound so negative it just seems like isolating by site (which is a logical, not physical barrier) is a more holistic solution which provides the isolation required, while allowing the DCs to continue to potentially (in an emergency situation) perform the duties of user authentication without having to change anything. The IPSec solution just seems like serious overkill that's unnecessary. On 9/13/06, Akomolafe, Deji [EMAIL PROTECTED] wrote: I thought his original request was to make sure that no other client talks to the isolated server except those permitted. Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_ (_/ /) (/ Microsoft MVP - Directory Services www.akomolafe.com- we know IT -5.75, -3.23 Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: Matt Hargraves Sent: Wed 9/13/2006 7:26 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Isolating a DC Isolating via site will still leave the DC available in case of emergencies (your authentication DCs go down), whereas IPSec makes them completely unavailable for any purposes for clients. I've actually never heard of anyone doing this and would consider it a very bad idea unless you have significant redundancy in your 'normal' environment. BTW, from a Microsoft presentation a little over a year ago, they have 4 Exchange server sites, only 1 of them (Redmond) isolates their DCs from authentication and reserves it for Exchange, the other 3 use their Exchange (a *very* DC/GC intensive app) servers for authentication also. Site is only a logical separation. IPSec might as well be a physical barrier. Unless there is a serious reason why you would rather have none of your clients to be able to authenticate instead of authenticating against these DCs (as I said, in case of an emergency), then you should probably avoid putting a IP filter on these boxes. If you isolate via site, then the only way that clients are going to authenticate against them is if all DCs are down in their site, which since you're a single physical site org, means that all of the authentication DCs are down, which is probably a more serious problem than OMG, a (gasp) *user* authenticated against my application DC. On 9/13/06, Lucas, Bryan [EMAIL PROTECTED] wrote: Thanks to all for the responses. This (isolating via ipsec) is probably the right direction for me. We're a single site, single domain at a single physical location, but the idea of building another site isn't appealing from a keep it simple perspective. Are there any technical reasons why a separate site would be better than isolation through IPSec?Will I cause clients/apps, who initially don't know they are denied, delays when they try to access the ipsec isolated DC? Bryan Lucas Server Administrator Texas Christian University -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of James Eaton-Lee Sent: Wednesday, September 13, 2006 5:39 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Isolating a DC Akomolafe, Deji wrote: I highly recommend that you read http://www.windowsitpro.com/articles/print.cfm?articleid=37935 Then, as a fall-back option, look for the isolation using IPSec whitepapers on Microsoft site. I can't find them now, but I know that they exist. They show you how to restrict communication with a specific server or network using IPSec. I think what you're referring to is the excellent Server and Domain Isolation using IPSec content, at: http://www.microsoft.com/technet/security/topics/architectureanddesign/i psec/default.mspx If all you're looking for is host-based firewalling, however, there's other content online that'll explain this a little more concisely, such as this presentation from the Virginia Tech
RE: [ActiveDir] Block Inheritance on DC OU
Are we actually talking blocking GPO inheritance, or ACL inheritance? If GPO I tend to agree with Darren (as with anything on GPO J), as I dont think that any change in either the Default Domain or the Default Domain Controller policy should be implemented without testing (so if blocking the GPOs was setup to protect the DCs it should give you more headaches than benefits as youd need to apply all policy settings from the domain policy separately to the default DC policy). If ACLs on the OU, I wouldnt say its a big deal. All the ACLs required for the DCs to do their work are set explicitly at the DC OU level. The inheritance really only matters for the pre-win2k compatible group ACE, which is not required on the DC OU (just happens to be set for inheritance from the root of the domain). Not saying its a good idea to block ACL inheritance on this OU, but it doesnt hurt you. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Wednesday, September 13, 2006 6:59 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Block Inheritance on DC OU Well, the obvious effect is that it prevents domain-linked policies from being delivered correctly, including password policy. This is probably not desirable. I can't think of a good scenario where this would be useful. Darren From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN Sent: Wednesday, September 13, 2006 9:37 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Block Inheritance on DC OU The company I am currently working for has block inheritance enabled for the Domain Controllers OU and apparently whoever enabled this setting is no longer with the company (or they wont fess up to why they did this). Although I am curious, what sort of ramifications does enabling block inheritance on the Domain Controllers OU pose? And what reason would you have to enable this setting on the Domain Controllers OU? With any other OU, it would be fairly obvious, but being that these are the Domain Controllers it would seem to be a unique situation. Thanks as always for your input, ~Ben
RE: [ActiveDir] Any impacts to domain controller when changingits IP?
Title: Re: [ActiveDir] Any impacts to domain controller when changingits IP? Yep, that was Win2k – once you’ve reached Win2k3 domain functional level, you can start adding another name to your DC, make it primary, reboot, ensure everything replicates well and registers in DNS, then remove the old name. Use NETDOM to do so. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Thursday, September 14, 2006 4:50 PM To: ActiveDir@mail.activedir.org; ActiveDir.org Subject: RE: [ActiveDir] Any impacts to domain controller when changingits IP? If you want to change the computer name you need toDEMOTE the server isn't that for w2k only? (he's got w2k3) Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto Senior Infrastructure Consultant MVP Windows Server- Directory Services LogicaCMG Nederland B.V. (BU RTINC Eindhoven) ( Tel : +31-(0)40-29.57.777 ( Mobile : +31-(0)6-26.26.62.80 * E-mail : see sender address From: [EMAIL PROTECTED] on behalf of Mark Parris Sent: Thu 2006-09-14 16:35 To: ActiveDir.org Subject: Re: [ActiveDir] Any impacts to domain controller when changingits IP? If you want to change the computer name you need to demote the server, wait for replication then change the server name at this stage I would re ip the server, then dcpromo the server again. This is of course assuming you have multiple DC's if not and it's only for 3 months keep then why not keep the name and just change the IP address. Make sure DNS functions correctly. Regards Mark Parris Base IT Ltd Active Directory Consultancy Tel +44(0)7801 690596 -Original Message- From: McClure, David (MED US) [EMAIL PROTECTED] Date: Thu, 14 Sep 2006 10:12:54 To:ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Any impacts to domain controller when changingits IP? If you're running a Certificate Authority on that DC, you can't change the computer name without first uninstalling Certificate Services. I'm not sure what the impact would be on the chain of trust if you reinstall CertSvcs after the name change. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Thursday, September 14, 2006 10:04 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Any impacts to domain controller when changingits IP? In SBSland they made a change IP address wizard for our DCs because invariably we forget something... DHCP WINS kitchen sink stuff, etc http://www.microsoft.com/technet/prodtechnol/sbs/2003/support/43dd693a-0 cc4-47fd-94c7-cfe200439f41.mspx?mfr=true You can see what the wizard does.. which is are the changes you will need to do Jobsz wrote: Dear all, Because our company is being merged by another company, in the process of integration we need change the internal IP address and computer name. Our domain controller of Windows Server 2003. We have to change its computer name and internal IP but no need to change The domain name, because we want to let run for 3 months. Anyone could tell me what impacts brought by these changes? Any suggestions would be appreciated! With best regards Jobs.Zhao 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 --- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you 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 .Š†ÿÁŠŠƒ²§²B§Ã¶v®Š§²rz§Ã¶v®—± This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and
RE: [ActiveDir] Seperate Administrator password policy
different passwordpolicies to different domain controllers. I would like this executed for all domain/domain controller security settings in general actually. From the standpoint of speed/perf, I am not sure if it makes sense to have an assemble the final policy on the flymechanism here. From a perf standpoint I don't think youwant to be having to do the logic to combine multiple password policies into one policy for every password change (which would be the case if you go to the user granularity level) and instead would just have an override mechanism. You can do this with regular GPOs because the clients individually are processing them, not the DCs. So for this, you would want to use the closest policy to the user as the one applied. The alternative here is if there was a builtin inheritance flowdown model like there is for ACLing where you can simply look at the one object and know exactly what the password policy iswhether the settings were higher up or directly on the object just like you can with ACLs. Either way, you need to be able to do a very simple query and very simply processing and get the decision for what the policy should be for the user. This isn't a good place in the code to be just hanging out trying to figure out what to do for a while. Using groups could be troublesome, what is the override mechanism, which group is more important if there are policies on 10 groups you are in? Whatever ends up getting done forpassword policy would be nice to see on kerberos and lockout policy as well. You shouldn't hopefully need to do it much with the former but there are times where I wish I had it available because the only other option was to open the policy for the entire domain regardless of the stupidity of the idea from a security standpoint. This has been a discussion point inside of MSFT for quite a long time now and I can assure you that anything that gets implemented/released went through considerable discussion by the developers inside of MSFT and to people outside outside of MSFT. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Crawford, Scott Sent: Friday, September 01, 2006 4:08 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Seperate Administrator password policy Ø of plans to allow setting password policies at the OU level What would be the direction theyd go to implement this? Since the setting is in the computer section of the GPO, it seems to offer all the functionality one should expect. And in fact, it is applicable at the OU level and it applies to computers [1]. It seems that the major reason people want to be able to set the policy at the OU level is so that it applies to users. The issue is that its a computer setting, not a user setting. IMHO, the only way to allow different password policies for different users, is to move the settings to the user section of the GPO. [1] It confuses me somewhat why DCs insist on pulling this from DDP instead of just assembling the policy, like any other, from all applicable GPOs. I assume it was done to avoid a situation where two DCs could have different policies applied to them and depending on what DC handled your password change, you would be subject to different rules. If thats the case, I cant say Im a big fan of illogical hacks to help out less-cluefull admins. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Thursday, August 31, 2006 7:58 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Seperate Administrator password policy Agree, a separate domain is certainly a very high price to pay itll cause ongoing headaches with very little benefit. Other companies add requirements for smartcard logons for Admins or also solve it via organizational rules as mentioned by ZV. Ive heard of plans to allow setting password policies at the OU level for Longhorn AD, which is due out mid next year. This could be wishful thinking (has been a request for quite some time), but I hope they make it. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Za Vue Sent: Thursday, August 31, 2006 2:39 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Seperate Administrator password policy Would it be easier just to ask them to use 15 characters? Run a small script to check on the numbers of characters after the passwords have been changed. If under 15 than ask them to change it again. -Z.V. Almeida Pinto, Jorge de wrote: third party software could be an option for example: http://www.anixis.com/products/ppe/default.htm jorge From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bahta, Nathaniel V CTR USAF NASIC/SCNA Sent: Thursday, August 31, 2006 14:15 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Seperate Administrator password policy Just
RE: [ActiveDir] Seperate Administrator password policy
;-) thanks for the feedback anyways Eric it gives us an idea that we shouldnt build our hopes too high for the multiple-password-policies feature at this stage in the LH development phase. But Ill keep hoping anyways. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Saturday, September 02, 2006 6:25 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Seperate Administrator password policy Is this a serious question? I have no idea. If I knew, not only would I do this, but Id run out and buy a lotto ticket immediately. g This isnt about NDA or not. We cant see in to the future like this. We do our best to build as much as we can. At some point, the gates close. What makes it in is quazi-predictable, but not to the level youre asking for. ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Saturday, September 02, 2006 2:15 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Seperate Administrator password policy Eric, can you already state publicly, what the chance of this feature is to make it into Longhorn, if at all? Or is this still NDA? Thanks, Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Saturday, September 02, 2006 6:32 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Seperate Administrator password policy A few comments, in no particular order I can visualize mechanisms to pull this off in the existing GPOs or to do it outside of the GPOs Well sureit doesnt take a visionary to see how this could be done. ;) See LDAP policies for one such example (though by no means the only choicein fact, not how I would do it). I would point out that if you pulled out password policy, it would make sense to pull out all policy dependencies in AD itself so as to fully separate the relationshipthat is, AD and associated components (SAM, Kerberos, etc.) do not depend on policy application for anything. If you leave the world of the GPO I think you get more flexible as you could then implement it in such a way thatthese password policies could be applied tousers within containers and evenspecific individual users which would be great for say service IDs or admin IDs Well, yea. I mean, this is the DCR that weve been asked for over and over for like 5 years. While there are many ways to achieve it (group memberships, direct links from the user parent containers, etc.) the net net is the same. From the standpoint of speed/perf, I am not sure if it makes sense to have an assemble the final policy on the flymechanism here efleis snip of the rest of the paragraph, but Im commenting on it all The reality is that I dont think most orgs will have thousands of password policies, so the merging is likely not all that bad. And the # of settings is low. That said, Im still against this as it seems uber inconsistent to me and very error prone. Using groups could be troublesome, what is the override mechanism, which group is more important if there are policies on 10 groups you are in? This is a trivially solvable problem, Im not worried about this. On the larger point of the right way to skin this cat, I actually disagree. I am for groups for the same reason Im for them in the RODC PRP scenario. Again, there are a great many orgs where you have OUs separated by many things, say geographical location, and now want to make an OU-separated set of lower-priv admins have some special password policy (imagine the regional admins scenario for a customer who has OUs separated by location). I really think the argument is very much the same as RODC PRP use of groupswe dont want to push an OU model here. Im typically against building features in such a way that they dictate a specific OU model to use them as that could fly directly in the face of the logic you used for your existing OU model. It confuses me somewhat why DCs insist on pulling this from DDP instead of just assembling the policy, like any other, from all applicable GPOs. I assume it was done to avoid a situation where two DCs could have different policies applied to them and depending on what DC handled your password change, you would be subject to different rules. Yes, thats why. In fact, there were some way early win2k bugs that yielded just this (like pre-SP1 if I remember right, or maybe even as late as SP1, Im not sure). If thats the case, I cant say Im a big fan of illogical hacks to help out less-cluefull admins. I love this sentence. J ~E From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, September 01, 2006 2:57 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Seperate Administrator password policy I can visualize mechanisms to pull this off in the existing GPOs or to do it outside of the GPOs.Having thought about this quite
RE: [ActiveDir] Seperate Administrator password policy
Agree, a separate domain is certainly a very high price to pay itll cause ongoing headaches with very little benefit. Other companies add requirements for smartcard logons for Admins or also solve it via organizational rules as mentioned by ZV. Ive heard of plans to allow setting password policies at the OU level for Longhorn AD, which is due out mid next year. This could be wishful thinking (has been a request for quite some time), but I hope they make it. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Za Vue Sent: Thursday, August 31, 2006 2:39 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Seperate Administrator password policy Would it be easier just to ask them to use 15 characters? Run a small script to check on the numbers of characters after the passwords have been changed. If under 15 than ask them to change it again. -Z.V. Almeida Pinto, Jorge de wrote: third party software could be an option for example: http://www.anixis.com/products/ppe/default.htm jorge From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bahta, Nathaniel V CTR USAF NASIC/SCNA Sent: Thursday, August 31, 2006 14:15 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Seperate Administrator password policy Just wanted to field this to see if it makes any sense to any of you guys. We are going to implement a mandatory 15 character password policy for all of our administrator accounts. The only way that makes sense is a subdomain with a separate password policy, since there is only one per domain. I also know that I have to edit the minPwdLength attribute and the uASCompat attribute to make this work on the subdomain. Can anyone think of another method of doing this? Thanks, Nate Bahta This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
RE: [ActiveDir] Logging successful logons in AD security log
That would be the Audit Collector Services (ACS) - been in Beta forever and due to internal struggles they couldn't release it for free. AFAIK, ACS is still planned to be a part of MOM. The Longhorn Eventsystem is a completely different story - can handle many more events (incl. great filtering capabilities) and has native capability to forward events to other servers (centrally collect on one or many LH servers). Not sure how the latter will scale, but it sure will be interesting for many companies. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wells, James Arthur Sent: Thursday, August 31, 2006 2:28 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Logging successful logons in AD security log I've been told by some folks at Microsoft that it won't just be Longhorn, but that Windows Server 2003 will have some native (and free?) options for collecting event log data into SQL and performing reporting, similar to what 3rd party products or custom development mentioned on this thread are capable of. I'm not sure if it will be more powerful than what can be done with LogParser, or just easier... There was also some mention of MOM packs to go along with it. I've not seen anything official yet, though. --James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Corbett Sent: Thursday, August 31, 2006 4:54 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Logging successful logons in AD security log Interesting. from the article: Microsoft plans to resolve these problems in the next version of Windows by rewriting the event logging system from the ground up. since the last update was Mar 28 2003, I wonder how this applies to Wndows 2003 R2 and the 64 Bit versions of Windows, or if this will only be fixed in Longhorn. Glenn From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris Sent: Thursday, 31 August 2006 7:20 PM To: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Logging successful logons in AD security log Does everyone know this recomendation from Microsoft? On Windows XP, member servers, and stand-alone servers, the combined size of the application, security, and system event logs should not exceed 300 MB. On domain controllers, the combined size of these three logs - plus the Directory Service, File Replication Service, and DNS Server logs - should not exceed 300 MB. http://technet2.microsoft.com/WindowsServer/en/library/5a86ab0f-c7eb-45e d-9e 5e-514173bf15e31033.mspx?mfr=true Mark Return-Path: [EMAIL PROTECTED] Thu Aug 31 04:12:18 2006 Received: from smarthost1.giacom.net [194.131.240.55] by mail1.giacom.net with SMTP; Thu, 31 Aug 2006 04:12:18 +0100 Received: from mail.activedir.org ([12.168.66.190]) by smarthost1.giacom.net with MailEnable ESMTP; Thu, 31 Aug 2006 04:12:15 +0100 Received: from smtp111.sbc.mail.mud.yahoo.com [68.142.198.210] by mail.activedir.org (SMTPD32-8.15) id A27721B0148; Wed, 30 Aug 2006 23:07:35 -0400 Received: (qmail 99368 invoked from network); 31 Aug 2006 03:07:35 - Received: from unknown (HELO ?192.168.16.19?) ([EMAIL PROTECTED]@69.106.185.80 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 31 Aug 2006 03:07:35 - DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Refer ence s:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PEIfvYwJhIYktsWE3wK8pnfo1RmbheeJg4LXCAQ1cS/3aIkBB+zWPBGoNL0vpHGQ7U+CwL +WPV R6qNv7o1jr4Xp9zMxBmnzKaUuWHbmSmTn++z6CEr/Q5njP0rjFViu7J0fVz2mvIfjfh29qkH R6qNv7o1jr4Xp9zMxBmnzKaUuWHbmSmTn++O6+P EuYRMiJ3/EUAyhoBySfo8= ; Message-ID: [EMAIL PROTECTED] Date: Wed, 30 Aug 2006 20:07:29 -0700 From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Logging successful logons in AD security log References: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: [EMAIL PROTECTED] Reply-To: ActiveDir@mail.activedir.org Received-SPF: none (smarthost1.giacom.net: mail.activedir.org does not designate permitted sender hosts) X-Declude-Sender: [EMAIL PROTECTED] [12.168.66.190] X-Note: This E-mail was scanned in real-time by Giacom Anti-Spam and Giacom Anti-Virus. Advanced Virus and Spam protection is available to subscribers of Giacom Business Pro Plus. Visit http://www.giacom.com for more details. X-Spam-Tests-Failed: ROUTING [-1] X-Note: This E-mail was sent from ([12.168.66.190]). X-Rcpt-To: [EMAIL PROTECTED] Ask the PSS security guys and they want success and failure. Only having half the story... is only half the story Buy bigger harddrives and
RE: [ActiveDir] Seperate Administrator password policy
Dont think that auto disabling them when they dont follow your organizational rules is too harsh. They will be certain to follow the rule in the future. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bahta, Nathaniel V CTR USAF NASIC/SCNA Sent: Thursday, August 31, 2006 2:58 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Seperate Administrator password policy I thought about that, but that does not prohibit you from setting a password less than 15 characters. I thought about setting it up to run on a changenotify event and then if the length was less than 15, disable the account, but I think that is a bit harsh. I dont know of a way of stopping the setting of a password less than 15 characters without a actual subdomain. That PPE looks like it would do the trick, but I dont think we are being given third party tools to implement this security measure. Nate From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Za Vue Sent: Thursday, August 31, 2006 8:39 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Seperate Administrator password policy Would it be easier just to ask them to use 15 characters? Run a small script to check on the numbers of characters after the passwords have been changed. If under 15 than ask them to change it again. -Z.V. Almeida Pinto, Jorge de wrote: third party software could be an option for example: http://www.anixis.com/products/ppe/default.htm jorge From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bahta, Nathaniel V CTR USAF NASIC/SCNA Sent: Thursday, August 31, 2006 14:15 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Seperate Administrator password policy Just wanted to field this to see if it makes any sense to any of you guys. We are going to implement a mandatory 15 character password policy for all of our administrator accounts. The only way that makes sense is a subdomain with a separate password policy, since there is only one per domain. I also know that I have to edit the minPwdLength attribute and the uASCompat attribute to make this work on the subdomain. Can anyone think of another method of doing this? Thanks, Nate Bahta This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
RE: [ActiveDir] AD Site replication settings/costs
For Win2000 AD thats quite a common approach. Really depends on how many domains you have and how youve placed your DCs of these domains. /Guido From: Rimmerman, Russ [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 1:45 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD Site replication settings/costs We made every domain controller (80+) in our forest a GC. We did this because if a link went down, we wanted each DC to be able to hold its own. Maybe this wasn't such a good plan? From: [EMAIL PROTECTED] on behalf of Laura A. Robinson Sent: Wed 8/30/2006 5:10 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD Site replication settings/costs No. GCs can replicate partitions thatthey don't own to other GCs. They can't replicate them to DCs for the domains in question, but they *can* replicate their read-only partitions to other GCs. Laura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Cliffe Sent: Wednesday, August 30, 2006 5:40 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD Site replication settings/costs That shouldbe GCs cannot replicate partitions they don't ownright? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laura A. Robinson Sent: Wednesday, August 30, 2006 5:05 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD Site replication settings/costs Is it a GC? If so, then yes, that's to be expected. You may have *thought* that you gave it only one replication partner, but if you're seeing additional connection objects, then it has more than one replication partner. When planning replication, you must be aware of every partition that the DCs in a site are hosting. If you don't want that remote DC to have connection objects from all of those other DCs, you're probably going to need to set up connection objects for preferred DCs for it to use for replication of partition data. If it's a GC, and if you have a GC that is a DC for the same domain in another site, that would be a good choice to set as a replication partner, because they would be able to replicate all of their partitions (GCs can replicate partitions they don't own to other GCs). Laura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ Sent: Wednesday, August 30, 2006 2:52 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD Site replication settings/costs It's a Windows 2000 native domain, we're about 4 upgrades from having all Win2k3 DCs and from what I've read, that should help a lot with replication. Automatic site link bridging isnt enabled, and we have 0 site link bridges. We're a worldwide company with 3 main hubs, but it is a mesh network in design (MPLS). I guess i'm mainly confused because the DC at the slow bandwidth site in question only has one replication partner, yet we see connections to it from a large number of our DCs on a regular basis. Is this normal? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laura A. Robinson Sent: Wednesday, August 30, 2006 11:12 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD Site replication settings/costs Intervals vary by company, domain structure, network topology and latency tolerances. That said, there is nothing inherently wrong with the replication parameters you list below. Are they the best parameters for your environment? That depends. Is this a Windows 2000 environment? Is automatic site link bridging enabled? There's a lot to consider in determining how to set site link properties; what you've listed below won't really be enough for anybody to give you any kind of realistic advice. (sorry) Laura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ Sent: Wednesday, August 30, 2006 11:59 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] AD Site replication settings/costs We have about 80 AD sites with DCs. All sites are set for a cost of 100 on the site to site replication, and a replication interval of 15 minutes. I'm presuming this is probably not a good thing. One slow bandwidth site is complaining that their DC is talking to every DC in the domain. What is everyone else using as a replication interval for inter-site replication? ~~ This e-mail is confidential, may contain proprietary information of Cameron and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~ ~~ This e-mail is confidential, may
RE: [ActiveDir] Printers AD GUI
I forget if this is unique to SBS's AD setup or what. but any
network attached printer will automatically get attached to each
workstation that is set up with the /connectcomputer wizard
I'm pretty sure this is unique to SBS - at least I would hope - nothing
like adding thousands of printer queues automatically to each
workstation :)
However, while we're discussing printer topics, it may be worth to point
out that Win2003 R2 has added a nice feature to automatically distribute
printer queues to computers via GPO. This is certainly useful for
branchoffices to auto-deploy specific shared printers to all machines in
a branch office site (incl. traveling users...)
This features is integrated with R2's Print Mgmt Console (PMC). It
attaches printer queue information to an existing GP object:
CN=PushedPrinterConnections underneath
CN=System,CN=Policies,CN={GPO},CN=Machine or
CN=System,CN=Policies,CN={GPO},CN=User (you will see a new node in the
GP editor called Deployed Printers on the R2 machine where the PMC is
installed). Your AD schema needs to have been updated to the R2 schema.
PMC is also installed automatically on any Longhorn Server to which you
add the Print Server role.
Note that the printer connections listed in the GPO are not added to the
clients by magic just because the GPO applies to them. For Windows XP
(and Windows Server 2003) clients, you have to run a specific machine
startup script or user logon script (pushprinterconnections.exe from
%WinDir%\PMCSnap) in the GPO. If you deploy to users, they must have the
rights to install printers... Vista (and LH server) do not require the
use of a script, as they have the logic to push the printer connections
built in. Afaik, there is no support to push the queues to Win2000
clients.
Naturally, it has been possible for years to push printer queues to
clients via scripts, but if you have a pure WinXP client environment
doing so via the PMC and GPOs could be quite attractive and reduce the
cost for maintenance of the scripts - especially for branch offices...
/Guido
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley,
CPA aka Ebitz - SBS Rocks [MVP]
Sent: Monday, August 28, 2006 9:08 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Printers AD GUI
The only printers up in my GUI AD are the ones hanging off the server
with an IP address.
Each workstation has a local printer and the last thing I'd want is to
have ...about 15 to 20 various versions of Laserjet 6L, 1100s and what
not in the printer drop down for everyone to buzz me and say which one
is my local printer again?
I forget if this is unique to SBS's AD setup or what. but any
network attached printer will automatically get attached to each
workstation that is set up with the /connectcomputer wizard
http://msmvps.com/blogs/bradley/archive/2005/01/23/33632.aspx
joe wrote:
But if a printer is not shared out to the network, is it a network
device?
It can only be used on the local machine.
Do you want every local printer on every single machine in a company
showing
up in the directory? Consider a large multinational with hundreds of
thousands of desktops and thousands with local printers that aren't
shared.
Then you want a printer with a certain capability in a certain site
and you
look and find one in the directory but it isn't actually shared out.
You try
to print to it, you can't. You call IT. They look into it and chase it
to an
exec who is like piss off. :) You tell the person they can't use it
and they
get snotty because everyone is better and more important than IT. :)
Horrible escalations. :)
You could always create your own printqueue objects for your
non-shared
printers. It sounds like they would get zilched back out of the
directory
from the process Brian mentioned unless you disable the pruning. The
other
issue would be the manadatory attribute for the share name but you
could
give it would be if it were shared. I don't know what this would buy
except
that you can see them when browsing AD.
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Albert Duro
Sent: Sunday, August 27, 2006 10:24 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Printers AD GUI
You will note that when you create
a queue, you get the option to publish it to the directory, it isn't
mandatory, not required, it is simply an option
of course, but ONLY if you share them. As soon as you stop sharing
them,
POOF
both you and Brian essentially said that yeah printers are not full AD
objects, and that's the way it is. But wasn't the promise of AD to
bring
ALL network objects (in the prosaic sense) into the manageability
fold?
There's no question that AD is vastly improved over NT as far as
printers
go, but I'd like to see the promise
RE: [ActiveDir] Read-Only Domain Controller and Server Core
=X CN=Group Policy Creator Owners,CN=Users,DC=X; CN=Domain Admins,CN=Users,DC=rX CN=Cert Publishers,CN=Users,DC=X CN=Enterprise Admins,CN=Users,DC=X CN=Schema Admins,CN=Users,DC=X CN=krbtgt,CN=Users,DC=X -Nathan Muggli RODC Program Manager From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Thursday, August 03, 2006 3:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Great information Nathan thanks! Certainly good to know how the msDS-AuthenticatedToAccountlist attribute is updated. What does PRP stand for? And is it correct to say that the PRP move feature in repadmin would directly populate the Password caching Policy of the RODC servers with each security principal (users, computers) that have authenticated to the RODC (as opposed to using some RODC specific security group)? Which means that all of these account references would be stored in the msDS-RevealOnDemandGroup attribute Hmm, while thinking about this, I wondered if this is only appropriate for smaller or even for larger environments. I was thinking about possible limitation regarding how many entries could exist in the msDS-RevealOnDemandGroup multivalue attribute and if theyd be replicated as a blob but from checking the schema, this is a linked attribute so I assume it also supports LVR (assuming at least FFL2; which I dont think is a requirement for RODC). Thus once FFL2 is reached there should be no limit as to the number of accounts to populate that attribute with. So basically if my assumptions regarding LVR capabilities of this attribute are correct, the msDS-RevealOnDemandGroup could be seen as the most appropriate attribute to populate the accounts directly, unless I really want to use or already have a security group. This way, I dont have to add another group to any users token. This would be cool even without repadmins PRP move feature, we could auto-populate the msDS-RevealOnDemandGroup attributes of the respective RODCs based on other queries, such as office etc. or a combination of the results including the Auth2 entries. The only downside would maybe be that there is no back-link to the objects, so I couldnt check a user account and see which RODC allows to cache its password (I know I can check the msDS-RevealedDSAs attribute to see where a user pwd has been cached). This looks very promising! /Guido snip
RE: [ActiveDir] management of group policy links (GPMC)
The GPMC scripts include the ListSOMPolicyTree.wsf script which at least creates a useful text report of which GPOs are linked to which OUs (and sites). Combine this script with the BackupAllGPOs.wsf and the GetReportsForAllGPOs.wsf to be well prepared to restore GPOs (and then link them back to where they were linked prior to deletion). /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, August 23, 2006 7:05 PM To: activedir@mail.activedir.org Subject: [ActiveDir] management of group policy links (GPMC) Dear all, as i recall / understand group policy links are stored as an attribute (gplink) of the OU. It seems that GPMC is fine at summarising the links on a per OU basis as you step down the forest / domain structure. However it seems to lack a summary of OU / linked GPO(s) / link order / security filtering / delegation Would seem to be helpful in the context of a documentation of an Active Directory, especially given the scenario of restore of a GPO which does not look to restore links, let alone the link order which would need to be restored somehow in the event of GPO restore. Thanks, as always GT List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] management of group policy links (GPMC)
Yep - but I'd also run the GetReportsForAllGPOs.wsf script during your backup job - these reports are very useful to discover what may have changed in a GPO after the last backup... /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, August 23, 2006 9:08 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] management of group policy links (GPMC) thanks both What this is all about is putting in place the necessary operational practices to ensure capability to restore in the event of scenario of restore of GPO. From both your notes it seems that with the backups of the GPO's themselves (backupallGPOs.wsf) together with the output from ListSOMPolicyTree.wsf scripts I have ALL necessary information for the return of the GPO (and the OU to which it is linked) to prior state Thanks Graham- The Inheritance and Delegation tabs (when you're sitting on a container object like an OU in GPMC) provides the information indicated below. I guess I'm wondering what you're missing from that? Its true that GPMC backup/restore does not restore links, link order or Enforced flags, but there are 3rd party products that can do this, combining GPO restore with the AD parts of that. Darren -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, August 23, 2006 10:05 AM To: activedir@mail.activedir.org Subject: [ActiveDir] management of group policy links (GPMC) Dear all, as i recall / understand group policy links are stored as an attribute (gplink) of the OU. It seems that GPMC is fine at summarising the links on a per OU basis as you step down the forest / domain structure. However it seems to lack a summary of OU / linked GPO(s) / link order / security filtering / delegation Would seem to be helpful in the context of a documentation of an Active Directory, especially given the scenario of restore of a GPO which does not look to restore links, let alone the link order which would need to be restored somehow in the event of GPO restore. Thanks, as always GT List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Exclude from GPO
Nope youll have to either create a second GPO without the setting and apply appropriate filters to both so that only one GPO is applied to your special set and the other GPO to all others. Or you trim your existing GPO so that it is more generic (i.e. it doesnt contain the unwanted settings for your group of computers) and create another one that only contains the special settings. In later case youd then only have to apply a filter to the special settings GPO so that its not applied to your group of computers that shouldnt get them. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, Devon Sent: Wednesday, August 23, 2006 10:04 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Exclude from GPO Is it possible to exclude a group of computers from ONE setting from a particular GPO, but apply everything else in that GPO? Id have to create a whole new GPO just for one setting. -Devon --- This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you.
RE: [ActiveDir] management of group policy links (GPMC)
No, in case you screw up a GPO (vs. deleting it by accident) there's no need to first delete and then restore the backed-up GPO. The values won't be merged - the existing one will be completely overwritten. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, August 23, 2006 10:14 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] management of group policy links (GPMC) Duly noted one other query on a similar note if we do need to restore GPO with GPMC say in the scenario of admin error is it better working practice to DELETE existing GPO, presumably wait for sysvol replication and then restore ?? seems the best way to get the 'clean state' and not have issues say of merged values ?? GT Yep - but I'd also run the GetReportsForAllGPOs.wsf script during your backup job - these reports are very useful to discover what may have changed in a GPO after the last backup... /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, August 23, 2006 9:08 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] management of group policy links (GPMC) thanks both What this is all about is putting in place the necessary operational practices to ensure capability to restore in the event of scenario of restore of GPO. From both your notes it seems that with the backups of the GPO's themselves (backupallGPOs.wsf) together with the output from ListSOMPolicyTree.wsf scripts I have ALL necessary information for the return of the GPO (and the OU to which it is linked) to prior state Thanks Graham- The Inheritance and Delegation tabs (when you're sitting on a container object like an OU in GPMC) provides the information indicated below. I guess I'm wondering what you're missing from that? Its true that GPMC backup/restore does not restore links, link order or Enforced flags, but there are 3rd party products that can do this, combining GPO restore with the AD parts of that. Darren -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, August 23, 2006 10:05 AM To: activedir@mail.activedir.org Subject: [ActiveDir] management of group policy links (GPMC) Dear all, as i recall / understand group policy links are stored as an attribute (gplink) of the OU. It seems that GPMC is fine at summarising the links on a per OU basis as you step down the forest / domain structure. However it seems to lack a summary of OU / linked GPO(s) / link order / security filtering / delegation Would seem to be helpful in the context of a documentation of an Active Directory, especially given the scenario of restore of a GPO which does not look to restore links, let alone the link order which would need to be restored somehow in the event of GPO restore. Thanks, as always GT List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] UAC Question
Adding a dummy workstation will hinder the user to logon interactively – this could be all you want to achieve. But it won’t hinder network logons – this may be undesired. Another thought – if the users aren’t really using their AD account, couldn’t you just change the PW to some complex dummy pwd? This would ensure that the user wouldn’t be able to use the account for any AD authentication – until they come back from their sabbatical and the helpdesk resets the pwd for them… Also, I’d check with the application vendor, if you can’t configure it to use an attribute other than the disabled flag to see if the account should be voicemail enabled or not. This would give you much more granular control over the matter – you could disable the AD account (which it seems is really what you want to do) while still leaving the voicemail intact. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Monday, August 21, 2006 6:57 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] UAC Question Why are the last two groups treated differently than the others? You may want to consider a different approach, such as changing to the workstations that they can logon to or expiring the account. On 8/21/06, David Aragon [EMAIL PROTECTED] wrote: Al, Thank you for your response, I willtry to elaborate, but first, let me start by saying that I was not invited to participate in thisapplication's selection, testing, or acceptance. One day it just showed up. That said ... The software we use for VOIP uses its own db for storing messages. It was supposed to be AD aware. It's not. It is (barely) LDAP aware.I've found that when a user checks their voice mail (after they enter in their pass code)the program only checks to see if their AD account is enabled or disabled. We do have a password policy that does exactly what you describe (locks users out for some period of time after x invalid attempts). We have also given the senior Help Desk staffthe ability to unlock an account under certain circumstances. We have some (acouple hundred) accounts that exist to handle the section or group vm for those areas where individuals that share a phone number. These, I have identified and developed methods that prevent them from being used as login accounts. I have also foundthat there are users that do not have a computer and never use a computer, but they have vm enabled on their phone. We also have users that take sabbaticals for 6 months to a year. It is these last two groups I was hoping to address with setting the UAC account lockout. Politically I can not disable the accounts. I have tried to add the accounts to the permanent lockout list which works, but when the last groups returns it takestime for us to remove them from the list. Again politically unacceptable. This makes us having the ability to set the account lockout very appealing. What I was looking for was a way to set the lockout bit. It was previously explained that the bit can not be set directly, but that by setting the lockoutTime to some non-zero value the account is locked (though I've found that the bit is not always set). My current research and testing is moving along that path. David Aragon From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al Mulnick Sent: Monday, August 21, 2006 6:33 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] UAC Question This part troubles me: (for example it will prevent a user from logging into a system, but not prevent them from getting their voicemail). Can you expand on that? To my thinking, if the account is locked out, then the user should not be able to use it. Period. End of story. No exceptions. Locked out functionality is there as a precaution to prevent misuse of the identity (ok, account.) Why would you want to subvert that? What benefit that cannot be achieved in another manner? Again, to my wayof thinking, there is no reason you would ever want to mess with it in your day to day. A better option would be to set it to automaticallyclear after a certain period which would prevent hackers, crackers, andscript kiddies(side note: set it to somethingthat would cause a cracker totake longer to realistically crack thanthe password changecycle) from obtaining the passwords of the accounts. For example, .5 hours lockout after x number of attempts means that for every x number of attempts, anyone trying to programmatically trying to guess passwords would have to pause for .5 hours before resumption. If you havehundreds of thousands of possible passwords and combinations, that can
RE: [ActiveDir] Authoritative Restore problems
Mike, can you be a little more specific about the steps that you took to do your restore? This should work fine using the ntdsutil - authoritative restore - restore object Cn=test user, ou=it,dc=mycorp,dc=com command. Obviously provided you previously took a backup, rebooted to DSRM mode and have restored the AD DB (SystemState) to the DC the Auth Restore needs to happen right after the restore of the SystemState, prior to the reboot of the DC. Check out the whitepaper I wrote with Gil (http://www.netpro.com/media/pdf/NetPro_ADDR_Guide.pdf). Pages 11 to 13 walk you through how to do an Auth. Restore of objects, and since you have R2 (includes SP1), you can go right to page 21 to see how to recover potentially missing links of your recovered object (such as group membership etc.). Hope you dont have a multi-domain environment and are heavily relying on cross populating domain local groups in all the domains in your forest this adds extra headaches for the recovery of the links (also described in the whitepaper). /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Hogenauer Sent: Friday, August 04, 2006 6:57 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Authoritative Restore problems Ive been asked to write a Disaster recovery doc for our company. Im trying to delete a single user account and do an authoritative restore of that account. (in a test environment of course) Before I deleted the test account I used adsiedit to verify the path to the account. Cn=test user, ou=it,dc=mycorp,dc=com From Directory restore mode, I can start the Authoritative restore but it always fails with: Could not find object with the failed DN: failed on component cn=test user. Authoritative restore failed Error 800 parsing input illegal syntax? Ive reviewed http://support.microsoft.com/?id=840001 and it says I must use quotes either way it fails. Ive even tried the workaround described in here: http://support.microsoft.com/?kbid=886689 Suggestions? Environment: Windows 2003 R2 Thanks in advance Mike
RE: [ActiveDir] Admt Migration question.
Nice one... :-) BTW, I didn't know GOWAN was still around - used to make great music when I still lived in Canada ;-) /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Strongosky Sent: Friday, August 04, 2006 1:33 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Admt Migration question. Fixed...nic driver...uninstalled and reinstalled and it workedgo figure... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Strongosky Sent: Thursday, August 03, 2006 2:27 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Admt Migration question. Hey everyone I'm going nuts here and I need some help Am trying to do a security translation on a pc using ADMT v3.0 and it gives me this error Unable to access server service on the machine 'MISMCGOWAN'. Make sure netlogon and workstation services are running and you can authenticate yourself to the machine. hr=0x800706ba. The RPC server is unavailable, We have completed about 30 pc's and this is the first one that is giving us fits... We rename the pc before the migration to confirm to our new naming standards. ( I think this is where the problem lies) This is what we have done so far to troubleshoot this. 1. Made sure services it has mentioned are running. 2. Made sure the Remote registry service is running. 3. Added the Preferred DNS entry of the AD Dns Server and Wins entries to the Ip properties of the nic. 4. Deleted the old wins entries and new ones as well, did a nbtstat -RR at workstation to register the names in wins. 5. Disabled the firewall service and uninstalled another firewall program that was on this pc. 6. Went thru and uninstalled programs that we thought might impact this problem. 7. When we try and do a start, run \\MISMCGOWAN\c$ it won't list the contents' of the C drive from the AD domain Controller that we are migrating this pc from. We are logged in to this DC as a source domain Admin that is a member of the local admin group on the pc. We get this error No network Provider accepted the accepted the given network path 8. Can login to machine as the source domain admin account. 9. Changed the Administrator's name to fit our new naming standard. 10. Changed the password to match the account that is doing the migration. It's a source domain admin account. Thanks in advance for any input.. john List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Authoritative Restore problems
Make absolutely sure that you type the DN correctly I just noticed you have a SPACE between user, and ou=it if you entered the DN this way, it wouldnt work P.S.: wont read the posts for the next two weeks since Im taking off for vacation tomorrow. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Hogenauer Sent: Friday, August 04, 2006 4:26 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Authoritative Restore problems Guido Yes, I took a backup of the system state, rebooted into DSRM - ran ntbackup and restored the system state, went to NTDSUTIL and then tried my Auth Res and it still failed. Which is why Im confused. I actually have read the article you wrote in your hyperlink, and I know you read these post so I was actually hoping to get your opinion. I will try again and let you know what happens. Thanks, Mike From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Thursday, August 03, 2006 11:14 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Authoritative Restore problems Mike, can you be a little more specific about the steps that you took to do your restore? This should work fine using the ntdsutil - authoritative restore - restore object Cn=test user, ou=it,dc=mycorp,dc=com command. Obviously provided you previously took a backup, rebooted to DSRM mode and have restored the AD DB (SystemState) to the DC the Auth Restore needs to happen right after the restore of the SystemState, prior to the reboot of the DC. Check out the whitepaper I wrote with Gil (http://www.netpro.com/media/pdf/NetPro_ADDR_Guide.pdf). Pages 11 to 13 walk you through how to do an Auth. Restore of objects, and since you have R2 (includes SP1), you can go right to page 21 to see how to recover potentially missing links of your recovered object (such as group membership etc.). Hope you dont have a multi-domain environment and are heavily relying on cross populating domain local groups in all the domains in your forest this adds extra headaches for the recovery of the links (also described in the whitepaper). /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Hogenauer Sent: Friday, August 04, 2006 6:57 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Authoritative Restore problems Ive been asked to write a Disaster recovery doc for our company. Im trying to delete a single user account and do an authoritative restore of that account. (in a test environment of course) Before I deleted the test account I used adsiedit to verify the path to the account. Cn=test user, ou=it,dc=mycorp,dc=com From Directory restore mode, I can start the Authoritative restore but it always fails with: Could not find object with the failed DN: failed on component cn=test user. Authoritative restore failed Error 800 parsing input illegal syntax? Ive reviewed http://support.microsoft.com/?id=840001 and it says I must use quotes either way it fails. Ive even tried the workaround described in here: http://support.microsoft.com/?kbid=886689 Suggestions? Environment: Windows 2003 R2 Thanks in advance Mike
RE: [ActiveDir] Vendor Domain
looked at these FDA regulations in the past it turned out that there was more liability by not patching. From the vendor: Let me start by thanking you for considering our support model and continuing to pursue supporting it in your organization. Our designers have architected the system to comply with Microsofts best practices. We have implemented our own .local domain in an effort to provide solid system integrity founded on Kerberos authentication and a single sign-on experience for your clinicians. Our system relies heavily on the integrity of the Active Directory structure. We have integrated the launching of services and control of processes using this Microsoft recommended model. It has been our experience that relying on a hospitals Active Directory structure is a dependency that has opened our customers up to liabilities for the integrity of our regulated medical device. I liken the servers to a respirator. Having an outside person, no matter how qualified, work on a respirator would be a concern from a clinical standpoint. We have witnessed Group Policies applied to servers in a more open environment. This is a liability we do not want to expose our business partners to. Any change, no matter how minute to our system, would endanger our validation and designation as aXXX regulated medical device and would open you to failing FDA auditing. Thanks From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, July 20, 2006 12:12 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Vendor Domain I would tend to agree except in the case of Exchange, I am ALL FOR Exchange being run in a separate single domain forest, it solves an incredible number of problems such as the GC/NSPI problems as well as administrative isolation, etc. The exception there is if Exchange is deployed in a decentralized fashion outto all of the sites you already have DCs at, at that point, you probably want to fight with the issues with it in the main forest. The biggest complaint I have seen for running a separate Single Domain Forest for Exchange is around provisioning and quite frankly, that really isn't all that involved and doesn't necessarily need a full blown MIIS/IIFP solution. It dependson what data isneeded where. If you need all of the GAL info in the main NOS forest as well as the Exchange forest then you looking more into metadat sync tools unless your provisioning is all being handled through a centralized mechanism and then that can be used to send the info in both directions and actual tie between the domains for syncing isn't necessarily required. But if this isn't Exchange, I would be curious to hear the details of the app and why they want a separate forest. Most vendors if they told me they did it in a stupid way that had that requirement I would beat and tell them to fix it. With MSFT and Exchange, that only works a little bit. :) -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Thursday, July 20, 2006 2:32 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Vendor Domain I think everyone would be conceptually opposed - would be good to hear the vendor's reasoning for this. What does the app do? What benefit do you have from running their app in a speparate (single domain) forest? I can think of many downsides, but if the app is supposed to protect really sensitive data (isolation scenario), this may potentially be the reason for them to demand a separate forest. Certainly not, if the same folks manage both forests though... So pls. aks them for more details - doesn't hurt to understand their thinking. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Figueroa, Johnny Sent: Wednesday, July 19, 2006 8:09 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Vendor Domain We are a 2003 Forest with an empty root domain and a single child domain. We have a vendor looking to bring in a product that utilizes its own domain and has a one way trust to our domain. I do not know anything about the product yet but I am almost conceptually opposed to these vendor domains. I am looking for pros and cons... really ammunition to say no. Thanks Johnny Figueroa Supervisor Network Operations Support Network Services Banner Health Voice (602) 747-4195 Fax (602) 747-4406 WARNING: This message, and any attachments, are intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or employee/agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying
RE: [ActiveDir] Exchange rollout - How much larger does NTDS.DIT become?
Ok, thanks for getting back to us RM. So my guestimate with 100k users was just slightly off ;-) But now I wonder what in the world you store in your AD to have the DIT grown to 650MB with your user and computer population. Is this 2000 or 2003? Have you disabled Distributed Link Tracking? /Guido -Original Message- From: RM [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 6:32 AM To: Grillenmeier, Guido Cc: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Exchange rollout - How much larger does NTDS.DIT become? On Tue, 1 Aug 2006 18:29:24 +0100, Grillenmeier, Guido [EMAIL PROTECTED] said: Richard doesn't seem to be too keen on giving us further details - too bad. Sorry, been busy... 400 unread msgs from this list, got some catching up to do. What does the current environment look like? How extensive is your Exchange deployment going to be? 4800 user accounts, 3500 computer accounts. Maybe 3000-ish Exchange users? I'm leaning towards doing 64-bit everywhere we possibly can. It does seem like the more forward looking option. RM 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] Revoke domain administrator's right to create GPO?
Well, at least Darren posted another mail regarding security by obscurity which this is. Its just like removing the Domain Admins group from the local administrators group on member servers to secure the member server Just because many of those domain admins dont know why they may be missing some permissions and have no clue how to fix it, doesnt mean that youre protected from them. Some may even cause more harm by trying to regain access once youve removed it for the group. And GPOs are certainly not your only worry in a domain with too many domain admins. So as many have already stated and Im happy to chime in - dont try to fix the wrong thing. Instead remove all those users from the Domain Admins group, which you would have otherwise not added to the Group Policy Creator Owners group Youll now need to find ways to delegate the tasks that the ex-Domain Admins performed when they were still in the group. For example you may need to create few groups and add these to the local admin groups on the appropriate machines (such as a ComputerAdmin and ServerAdmins groups that will grant admin access to all workstations and member-servers respectively if this is what your admins need). Then add those ex-Domain Admins to these groups. Your Domain Admins can add these groups to the local admin groups on the respective machines via Group Policy /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Monday, July 31, 2006 11:24 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Revoke domain administrator's right to create GPO? Andy- Yes, its possible. There are actually two steps here. If you have GPMC, highlight the Group Policy Objects node on your domain and choose the Delegation tab. From here, you can delegate which groups can create GPOs in the domain. However, even if you remove Domain Admins from this list, what you will notice is that, when a GPO gets created by someone legitimately, the Domain Admins group will still have edit rights over that GPO. This is because the defaultSecurityDescriptor attribute on the groupPolicyContainer schema class object includes this group when any new objects are created. In order to change this, you will need to modify this attribute in the schema (e.g. using ADSIEdit) to remove that group from the SDDL list stored in that attribute. 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. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Wang Sent: Monday, July 31, 2006 12:42 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Revoke domain administrator's right to create GPO? Hi, I have a Group Policy delegation question. By default, only domain administrators, enterprise administrators, Group Policy Creator Owners, and the operating system can create new Group Policy objects. Since our company has lots of domain administrators, I'm thinking revoke domain administrators rights to create GPOs, then add only several of them to enterprise admin group / Group Policy Creator Owners. Is it possible? Thanks in advance. Andy
RE: [ActiveDir] Exchange rollout - How much larger does NTDS.DIT become?
Richard doesnt seem to be too keen on giving us further details too bad. But not sure why you Matt - are talking about breaking 1.25 GB with respects to the 32-bit capabilities. By default 32-bit Win2003 DCs can cache a DIT up to approx. 1.5GB, which grows to 2.6-2.7GB using the /3GB switch (provided sufficient physical memory). But irrespective of these limitations, Id argue you should move to Win2003 64bit DC anyways if you can. For example if you are doing a hardware refresh at the same time. It is cheaper (meaning you can support more memory for less licensing costs) and it will give you much more room to grow for the future. 64bit drivers for x64 server hardware are no longer an issue and even other important add-ons and management tools such as AV and Backup etc. are catching up quickly. So try not to use the 32bit WinOS versions for AD DCs, even if they still handle the load today youll do yourself a favor by moving to 64bit DCs as soon as you can. Time to learn all those little quirks and challenges around handling this OS. This way youll be best prepared for when you really need to use 64bit Windows for other applications. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Hargraves Sent: Tuesday, August 01, 2006 12:02 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Exchange rollout - How much larger does NTDS.DIT become? I guess the gist of what everyone is saying can be summed up with the following: What does the current environment look like? How extensive is your Exchange deployment going to be? Without some of that information, it's only going to be a vague guess that anyone can give. I seriously doubt you need to worry about breaking 1.25 GB, which is still well within the capability of a 32-bit server to handle. On 7/29/06, joe [EMAIL PROTECTED] wrote: To further add to this, it depends considerably on how populated you want your GAL to be. Some people just let the mandatory Exchange attributes get populated, others want the GAL to be the one stop shop for info on employees so everything goes into the GAL which means everything goes into AD. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Grillenmeier, Guido Sent: Friday, July 28, 2006 4:41 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Exchange rollout - How much larger does NTDS.DIT become? Assuming this is after defrag, 650MB without Exchange is quite a large AD guess you'd be close to 100k users in your forest, if you've used the standard attributes of the objects in AD (and haven't added stuff like thumbnail pictures to your users). After adding the Exchange schema mods, the DIT shouldn't grow substantially, since AD doesn't use any space for unused attributes and the Exchange attributes for your object won't 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 you'd 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] Exchange rollout - How much larger does NTDS.DIT become?
Not disagreeing with you Matt were all just in a guess mode without RM providing more information. I love those posts to lists where the original poster never gets back the questions being posted to his questions Anyways I just made the point that his DIT size is not small for a company not running Exchange. The number of users given was just an example more likely 100k vs. 5k users And naturally most corporate environments then have a similar amount of computer accounts and a strongly varying number of groups (totally depends on group model being used). And even if his AD already included Exchange we couldnt easily tell how large his environment is, simply because there are so many dependencies. Thats why I gave those numbers using assumptions certainly nothing to take as a fixed value. Heck, we dont even know his DC version (Win2003 single instance storage of ACE has a huge impact on DIT size) or if he has disabled Distributed Link Tracking (DLT), which adds a ton of garbage to every DC. Provided you have sufficient file servers in your AD and are happily moving data around between the servers (or between volumes), DLT alone can eat up many hundred meg of your AD DIT. Did he defrag or not? Etc. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Hargraves Sent: Tuesday, August 01, 2006 10:46 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Exchange rollout - How much larger does NTDS.DIT become? I'm not sure what else he's running on his DC. He might be running complex intrusion detection software, DNS, WINS, etc I have to assume that he's got 4GB worth of RAM and plenty of 'crap' (ok, maybe not crap, but you know what I'm saying) running on the DC that I'm sure plenty of us would love to see running on a different box. The 1.25GB comment wasn't regarding any limitations to 32-bit Windows. It was more involving I seriously doubt that your DIT is going to double in size unless you're populating as few as possible fields and have like 3 groups per user than anything. You made a comment about him having a large environment with 100k+ users to have a 650MB DIT and I just kinda went Huh? because we're running a 3+GB DIT with just over half that number. Every environment is completely different and there are a lot of different things that impact the DIT outside of user count. Groups, GPOs, OUs, computer objects etc user count might be a reasonable guage, but I don't think that ~6k DIT per user object is a reasonable assumption unless it's a newer environment with a nice spanking new RBS model. On 8/1/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: Richard doesn't seem to be too keen on giving us further details too bad. But not sure why you Matt - are talking about breaking 1.25 GB with respects to the 32-bit capabilities. By default 32-bit Win2003 DCs can cache a DIT up to approx. 1.5GB, which grows to 2.6-2.7GB using the /3GB switch (provided sufficient physical memory). But irrespective of these limitations, I'd argue you should move to Win2003 64bit DC anyways if you can. For example if you are doing a hardware refresh at the same time. It is cheaper (meaning you can support more memory for less licensing costs) and it will give you much more room to grow for the future. 64bit drivers for x64 server hardware are no longer an issue and even other important add-ons and management tools such as AV and Backup etc. are catching up quickly. So try not to use the 32bit WinOS versions for AD DCs, even if they still handle the load today you'll do yourself a favor by moving to 64bit DCs as soon as you can. Time to learn all those little quirks and challenges around handling this OS. This way you'll be best prepared for when you really need to use 64bit Windows for other applications. /Guido From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Matt Hargraves Sent: Tuesday, August 01, 2006 12:02 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Exchange rollout - How much larger does NTDS.DIT become? I guess the gist of what everyone is saying can be summed up with the following: What does the current environment look like? How extensive is your Exchange deployment going to be? Without some of that information, it's only going to be a vague guess that anyone can give. I seriously doubt you need to worry about breaking 1.25 GB, which is still well within the capability of a 32-bit server to handle. On 7/29/06, joe [EMAIL PROTECTED] wrote: To further add to this, it depends considerably on how populated you want your GAL to be. Some people just let the mandatory Exchange attributes get populated, others want the GAL to be the one stop shop for info on employees so everything goes into the GAL which means everything goes into AD. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL
RE: [ActiveDir] Read-Only Domain Controller and Server Core
RODCs do NOT replicate a subset of objects = right now they basically replicate everything a normal DC has (i.e. the full domain NC, config and schema), less the password hashes of any users. The OU vs. group discussion was solely around configuring the so called Password Replication Policy (bad name) for an RODC and after discussing this here and offline, doing various tests and elaborating about possible usage scenarios, I agree that configuring this policy by OU doesnt really give you enough flexibility. I would actually love to configure it by an LDAP query leveraging any appropriate attributes but this is simply to resource intensive during the authentication. Leveraging groups gives us the option to automatically provision the memberships appropriately though. Dont forget, youll have to do this for users and computers. Why is Password Replication Policy a bad name? Because thats not what it does calling it Password Caching Policy would be more appropriate, as an RODC would never store a users pwd-hash unless he has logged onto that RODC. Once the pwd is changed, an RODC will NOT update the hash it will only be updated the next time a user uses that same RODC. I dont mind this mechanism it provides an automatic cleanup mechanism and thus lowers the attack surface if a policy allowed many RODCs to cache a users PWD. But the name Replication Policy suggests that an RODC would actually replicate the new password when it is changed on a WDC (writeable DC), which is confusing. Replicating only parts of a tree (i.e. only specific OUs) would be a totally different story, which I also hope to see in the future (but wont be part of this version of RODC). However, RODCs will also be able to replicate the GC partitions (making them an ROGC) but from what I understand this will only be sufficient for authenticating, but not to be used as a GC for Exchange (I guess since Exchange simply needs that writeable domain partition). So placing an ROGC in a remote site will not be sufficient if you also have an Exchange server in that site. Exchange 2007 edge servers is yet another different story not sure if they can benefit from RODCs. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Mayes Sent: Monday, July 31, 2006 1:39 AM To: activedir@mail.activedir.org Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Apologies as Im reading in digest. But I just wanted to chip something into this surrounding OUs versus groups as it was something that Ive been thinking about on my mind-numbing commute. I understood that RODCs could be configured to be a read only subset of objects (users) from the writeable AD, or that you could set them to cache which would also be useful to catch user population at a given site if this was unknown. I remember there being a long discussion at the back of DEC about people wanting the subset replication to be based around OUs rather than groups, and lots of people being quite passionate about it. The thing that struck me was how would you then deal with group membership where the group was sat in a totally different part of the tree? Somehow youve got to get that closed set to work with, which is very loosely linked to migration strategies. (Blimey I must have paid attention on that migration course all of those years ago.). And then youve got constraints on OU structures for if they are now partitions for replication in some capacity. How wrong is this understanding? If its kind of right, then at some point in the future are we going to see multiple domain partitions hosted on DCs? Cos that would be nice as well as the ability to replicate subsets as read only. Where a GC could hold writeable copies of domain partitions that werent from its particular domain in the forest.. etc mmm DC consolidation, the possibilities! Then going more OT. There were also rumblings about ROGCs so that didnt contain sensitive info and could be used purely for email purposes without the baggage of a full fat DC. Is this correct and how does this relate to Exchange 2007 and its Edge servers, which from what I can gather are looking to suck bits of the AD into an ADAM for kind of the same purpose as an ROGC would perform? I may be totally babbling now. RE: [ActiveDir] Read-Only Domain Controller and Server Core From: Grillenmeier, Guido [EMAIL PROTECTED] Date: Sat, 29 Jul 2006 17:14:51 +0100 Al, thats basically getting back at what Eric said and the more I think about it, the more I have to agree: there is only a certain percentage of companies that are able to setup an OU structure by geography and certainly no single OU structure will fit for all companies. I have myself worked with quite a lot of customers, where OUs by location made sense but also some that had a mix of location-OUs for computers and business units-OUs for users. And others simply adjust it to their helpdesk model
RE: [ActiveDir] Read-Only Domain Controller and Server Core
Not sure if it makes sense, but this could potentially be combined with the confidential flag RODCs wouldnt cache any confidential attributes, unless a Confidential Data Caching Policy would allow them to do so The confidential flag is already used by the Digital Identity Management Service (DIMS) for the Credential Roaming feature. And instead of adding yet another flag to differentiate attributes which contain secrets or sensitive data, this may just be the right flag. Granted, none of this will make life easier for app developers. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Puhl Sent: Monday, July 31, 2006 10:05 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Youre right Joe that the RODC PAS would complicate things for the developers. The easy solution would be for developers to use the writeable flag when connecting to a DC, then theyd be guaranteed to not get an RODCbut even that isnt a great solution, and if we get the RODC GC it only becomes more complex. For general background though, the justification for the RODC PAS DCR is actually that there are numerous attributes which contain password hash, or password-like data. Because these attributes arent part of the pre-defined list of secrets, they are replicated normally rather than on-demand via the PRP. It wouldnt do me much good to prevent replication of 5 password attributes, when a 6th one which also includes a hash gets pushed down through normal replication. There needs to be a way for an administrator to define where these secrets live and protect them accordingly. Ive broached the topic of using this method to protect PII data a couple of times in relation to some RODC work were doing internally, and the response is always that its firmly in the realm of unsupported followed with a thatd be a bad idea and some serious head shaking simply because of the way applications behave. Brian From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, July 30, 2006 5:08 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core I am not sure if I understand where you are going but let me explain where I am coming from. First, the passwords being there or not being there is not important for this talk, that is already built in and will be there, now the discussion is around everything versus an RODC PAS. Everything is already there as well but is an important option because it will be the most used option. Actually I expect to see a ton of RODCs deployed that are configured as replicate everything including passwords so that people get the RO part of the benefit and they don't have to worry about replicating bad stuff back into the real directory and not have to worry about password caching management, if someone logs on somewhere, the password is cached there, bob's your uncle have a nice day. So now we get down to replicating a portion of the normal attribute set. Why would you want to do this? Because you want to minimize the traffic to WAN sites and/or reduced info in some locations in case of compromise. For instance, if the email addresses of everyone in the company isn't on a DC in a WAN site and someone steals that DC hoping to get those email addresses, they are SOL; they missed. However, now think about this from a application developer standpoint and it is the same issue that exists with GCs only worse because it is DCs. If an app developer wants to find something, they need to understand what they can actually find in the GC in terms of what attributes are populated. Maybe they (a) put in a requirement and hope people follow it, maybe they (b) actually try to verify it, maybe they (c) say screw that and query a DC instead because they know all of the data is there for a full query. >From what I have seen the likely cases for an app that can handle any query is C, A, and in the absolute blue moon case B. Usually the app will just fail to find what it needs if you specify an attribute that isn't in the GC. How does Exchange do it??? So there are hybrids like where certain things that people KNOW will always be in GC PAS and they will set it up so that queries using those things will use a GC and everything else will go to a DC. We already know that the same override that exists for the GC PAS would have to exist for an RODC PAS so why not just make that the other option and be done with it? I don't really see the majority of developers doing this any better with RODCs than they do with GCs and so it seems like a lot of make work to allow for the flexible handling of that if you just say these are the options. Again also the password thing isn't even worried about at the app level since apps can play with those anyway. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
RE: [ActiveDir] W2K3 Upgrade Domain Controller or Exchange Servers?
We thought to upgrade the DC's first because it takes care of the extension of the schema and all which has to be done prior to EXCH2K3 anyhow The upgrade of the DCs does not take care of the schema extension youll have to prepare your schema as a separate step prior to being able to upgrade any DC. And while youre updating the schema for your Win2k3 DCs, you may as well update the schema for E2k3 as well. Best procedure is actually to first update the schema with the E2k3 extensions, let it replicate, and then do the W2k3 schema extensions (this way you wont have the E2k schema conflicts with the W2k3 schema). And instead of using the base W2k3 schema, it doesnt hurt you to use the W2k3 R2 extensions. After extending the schema appropriately, it doesnt really matter if you first take care of your Exchange Servers or the DCs. Just need to make sure that you upgrade the Exchange app itself to 2003, prior to upgrading the WinOS of the cluster to W2k3. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bahta, Nathaniel V CTR USAF NASIC/SCNA Sent: Monday, July 31, 2006 3:37 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] W2K3 Upgrade Domain Controller or Exchange Servers? All, We are rounding home base in our upgrade path to 2K3 and have our Exchange Server Cluster runningW2K and EXCH2K and our Domain Controllers to upgrade lastly. Which of them would you think would be the best to upgrade first? We thought to upgrade the DC's first because it takes care of the extension of the schema and all which has to be done prior to EXCH2K3 anyhow. I cant think of a reason to not upgrade the Domain Controllers before the Exchange Server. Can anyone else? Thanks Nate
RE: [ActiveDir] Read-Only Domain Controller and Server Core
Ofcourse OUs dont fix the underlying challenge of knowing which user belongs to which site. And once tools exist to automate this knowledge whether by populating groups or attributes (such as office or address) or leveraging an OU structure, it really doesnt matter which mechanism is used to configure the RODC policies. However, many companies have organized their AD with a geographic OU structure, which doesnt necessarily match 100% to their site structure, but certainly gets pretty close. And since the delegation model is often configured such that local admins manage particular aspects of the users and computers in their site, it is a common practice to move a user account from one OU to another when the user is relocated to a different location within the company. As such the OU structure is often a good starting base to build policies for which credentials to replicate to which RODC I do agree that a lot of the same customers tend to have a security group that matches the OU a user is located in, simply because an OU is not a security principal and thus you cant use it for permissioning (another long missed feature from Netware). The problem is that without automation tools (and there are still plenty of customers without these), the OU-specific users group wont necessarily be updated as consistently when a User account is moved from one OU to another. I am sure that at some point it is a performance thing not sure how this password replication mechanism actually works in the background, but I think an RODC needs to make decisions at the time of logon of a user: during the logon process the RODC must determine if it should cache (and then continue to replicate) the users credentials or not. And I guess a users group-membership is analyzed faster than figuring out the OU that a user belongs to. Naturally, query based security groups wouldnt help to improve performance, but if you could add some nice processes from MIIS to AD that periodically and dynamically populate AD groups based on LDAP queries (without the need to support another database), this would certainly help. And the I would be all for using groups instead of OUs ;-) /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Friday, July 28, 2006 11:02 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core And currently this is all based on group memberships. I hope to see an option coming up to use OUs instead. To be clear, OUs are a Guido likes the way this looks feature, not a this helps the problem feature. The crux of the problem is figuring out who to cache on a given RODC. If you know thisby OU membership or something elseconstructing a group with said membership is trivial. However, if you dont know this, OU based policy is not going to help. With that, Ill state in public that my vote is not to build OU based policy. Why? Because it doesnt fix the problem. Instead, I want to spend our engineering dollars building tools to help users find who should be cached whereie, tackling the problem itself head on. Whether you then organize by OU or just populate groups is the easy part. ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Friday, July 28, 2006 1:33 PM To: ActiveDir@mail.activedir.org Subject: 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
RE: [ActiveDir] Read-Only Domain Controller and Server Core
Only if your sisters name is Cindy ;-) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Crawford, Scott Sent: Saturday, July 29, 2006 8:42 PM To: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Well, since you offeredI'll take a large pan pepperoni and mushroom. From: [EMAIL PROTECTED] on behalf of Eric Fleischman Sent: Sat 7/29/2006 11:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core I want to make one other thing clear.the other reason to ship the product in this state is secure by default. Out of the box, we have no idea what secrets you will want on the RODC. We dont know your enterprise or your threat model. As such, theres really no good choice.we too would be implicitly turning the knob for better out of the box admin experience vs more secure out of the box. No good choices. So, even if you assume that this state is good for no one (a contention Ill disagree with, there are some enterprises that will do this, but thats not the point), it is still the right state in which to ship the product. This is like ordering pizza for every admin in every forest on the planet. ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Friday, July 28, 2006 3:28 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core That's the ~Eric we've come to know :) Thanks for that view. I'll take your advice and check for the traffic and rethink the view on the RODC concept. Like you said, it may prove uninteresting, but after that amount of information from you, Dmitri and Guido, I'd hate to leave that stone unturned. I'll ping back if I get lost watching the traces. I appreciate the offer and you guys taking the time to discuss this. Al On 7/28/06, Eric Fleischman [EMAIL PROTECTED] wrote: 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 don't 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. That's what I was talking about re: the knobs.you can turn said knobs and make decisions that work for you. And we'll 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 haven't done enough investigation yet to really know if that's true or notit's
RE: [ActiveDir] ldp in ADAM-SP1
Or buy the book in the signature and find out how to step around this limitation... ;) well, as I know this workaround I'd comment that it's none of long-term value. At some point you're going to be faced with upgrading your forest to a new Windows Server release and then you won't have the luxury of allowing an older Win2003 DC to exist in your infrastructure (just to mange confidential bits that the updated and newer DCs won't let you set...). Unless ofcourse, you don't want to leverage the new features of the new WinOS... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, July 29, 2006 9:13 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 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. Or buy the book in the signature and find out how to step around this limitation... ;) 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). I agree with this and take it a step further. If you are constantly adding new sites or what not that need special ACEs that aren't handled through inheritence from existing structures I highly, no SUPER HIGHLY recommend spending a good amount of time and scripting the creation of those structures and those ACL changes. Yes this means actually have some form of fixed structure. This irks a lot of people but ad hoc OU structures do not work well in large orgs. It is a mess to figure out what is going on when you do that and at someone point, someone always wants to know what is going on. Plus if done that way, it certainly is a lot more efficient to do that work. In the widget company I immediately put together a script to do that stuff and an OU structure that exists for every building in the company that has something like 10 or 12 subous and several groups and lots of special permissions is created in less than a minute correctly each time. By hand, you would be talking 15+ minutes of work and who knows what would be screwed up. Plus... If something happened and all of the ACLs somehow got torched, you can run the script for each of the building OUs and everything is re-ACLed again. I didn't just start doing that on AD, I have done that on NTFS file systems for years because I was often asked as far back as the mid-90's who had access to what and where so I made sure that the permissioning model was shallow and simple. For instance in a project shared folder everyone had access to the top level, and then there was usually 2 groups for every top level folder under that shared folder, one for READ, one for CHANGE. You were in one group or the other and there was no other ACLing below that first folder level. It is much easier to put back together and very simple to work out who has access to what. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, July 25, 2006 9: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
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
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] 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
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] Migration without domain admin rights possible?
you can migrate most objects from the source even without admin rights to them - the default auth. user already has plenty of permissions to read most attributes you would care to migrate. You could still setup passwords migration without giving themdomain admin privs to your source domain - you would install the PES server for them instead on one of your DCs (you'd need to exchange the PES key ofcourse). Migrating SID history on the other hand, requires admin privs on the source domain = while you can delegate SIDhistory migration to the target, I've always complained that you can't delegate it on the source. Full control on the respective Users OU in your source domain is not enough. But if they do their part right (i.e. reacl all their resources in a two step approach 1st add new acls prior to "activating" the target accounts, 2nd remove old acls after all users use the new accounts),they don't really need SIDhistory and can spare themselves from having to clean it up later. You'll still have the same challenges with apps as you always do and if you also use exchange, then migrating their mailboxes is a totally different story. Another special challenge in your scenario is group migration = depending on how your security model is setup, they may very likel need to migrate groups that don't "belong" to them, but that they need to have access to their resources (and allowing to re-acl them). This doesn't mean that they need to migrate the members that don't belong to "their" unit, but they do need read permissions on most of your groups (which most users have by default anyways...). /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamlesh ParmarSent: Thursday, July 27, 2006 9:27 AMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Migration without domain admin rights possible? Hi Guys, We have a peculiar requirement, that one of the small group of around 300 users will be parting from corporate AD and will be setting up there own forest. We will be using ADMT 3.0 for migration. source DFL FFL : windows 2000 native Target DFL FFL : Windows 2003 Two way trust between domains. We would be givingFULL controlrights over those 300 users and their computers account to new admins of new forest. also, they are added to local admins of those computers to be migrated. They have domain admins rights in Target domain. We don't want to add them into administrators group on source domains (i.e. corporate AD) Is it possible to migrate, users,groups and computers? What will break, in migration? I can think of, we will not be installing PES as a result so, NO password migration. anything else? Thanking you in advance,-- Kamlesh~"Never confuse movement with action."~
RE: [ActiveDir] ldp in ADAM-SP1
I guess Matheesha's original question has been answered as good as it can for now with the information given. I just quickly want to comment on the 3rd party tool aspect joe is mentioning below - naturally, before spending considerable money on the tools, you'd need to test if they do what you want them to do in the first place. What I've found from many years of leveraging and checking different ACLing tools is that they also just go so far... I've had various different customer requests, which could not be achieved with the tools, but could be achieved with the native ACLs (mostly talking AD here). After getting over the hurdles of the basics, scripting quickly becomes your friend. I am not saying that 3rd party tools aren't quite useful for general ACLing stuff - it's when your own security model is complex, the tools will often not be able to help you reach your goal. Often this is a result of the complex ACLing rules build by MSFT themselves. Very hard for a developer to keep up with all changes (think of all the changes in Win2003 compared to 2000 and then with Win2003 SP1) and to understand the plethora of rules, especially when it comes to combining specific ACLing settings set at totally different places in the directory. A great example for this are various options to controlling delegation of password settings (I've written this up internally and for my upcoming Windows security book, as joe had been pointed at in his other reply). Win2003 provides three new not so well known extended rights, which allow domain admins to control which delegated admin can change critical password attributes on user accounts: * Enable-Per-User-Reversibly-Encrypted-Password * Unexpire-Password * Update-Password-Not-Required-Bit The challenge: these extended rights are set at the domain level, while other permissions to control which delegated admin can do what in an OU (e.g. create and manage users) are typically set at the OU level. So if you give a delegated admin full control over users, he would for example not be able to set the Password never expires and the Store password using reversible encryption options on the user accounts he is allowed to fully control, UNLESS he is ALSO granted the appropriate extended right at the root of your domain (Unexpire-Password and Enable-Per-User-Reversibly-Encrypted-Password in this example). This is certainly challenging for any domain admininstrator and moreso for 3rd party ACLing tools. Realize that by default the three extended rights I have mentioned above are granted to Authenticated Users, which means that any delegated admin who is also granted the rights to control the account restrictions of a user can set the respective password options. As these are rather sensible settings though, I'd rather disable any delegated admin from setting them (which is why the extended rights have been added to Win2003 in the first place). If you have different admins allowed to create users, just check out your domains and see how many users are configured with the password never expires flag - you will quickly understand what I mean. But again: it is very tough for 3rd party tools to remove default rights for you = they usually just handle adding permissions and it is up to you to fully understand the ACLing concepts of Windows to make everything work correctly. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, July 24, 2006 7:00 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Yes the tools are not quite what they could be. A lot of this is based on the complexity of the subject. The model is quite cool but it is also quite complex and getting more so. Look at the confidential attribute hack and the extended rights for protecting userAccountControl (Update Password Not Required Bit, etc). When you take into account all of the special rules in the DIT (usually around SAM attributes) which conflict with schema definitions as well as the special cases of ACLing like the confidentiality bit and the userAccountControl modifiers etc, the inheritence model it is very difficult to write one tool to handle all of the various cases to tell you what you have and to help you get to what you want. An additional difficulty is that Microsoft isn't quick with updating tools to handle new features. Now third parties get into this realm and start playing but for many people that just pisses them off and makes them say... Hey Microsoft should already be supplying this, I'm not buying something. That combined with the fact that just maybe MSFT will realize they should correct this will tend to kill most third party folks from even going into that realm. Oh another additional complexity and LDP actually exposes this. You could create a tool that could build any kind of ACL you want without making any judgements on what is being done so that at a later time if something changes the tool
RE: [ActiveDir] ldp in ADAM-SP1
to the relevant role. So you see, as there is a lot involved and this is a big infrastructure to attempt to administer perms for 20,000 users plus many OUs used to organise users based on the business unit (at least a dozen in each geographical hub) they work in and the site (we have more than a 40 geographical hubs and 1000 satellite sites) they are located at. Different levels of data admin roles. I would like to get this right to a large extent from the moment go. Admittedly it may not be big as in Fortune 5 ADs. But its the biggest I've had the privilege to design and support. I figured if I test this using the case study as a lab, I will get a good feel of whats involved in my lower level design. I am getting a little miffed when I have to swap between several tools to do what I need to do. There is just so many buts and ifs. You can do this but you cant do this. To do this use this. For this use that. And then try this. If all else fails script I admit I was ranting a bit when asking why is this named and like such and the discrepencies in the docs and syntax help of command line tools. My sincere apologies for been anal. Is it too much to ask, to have at the very least a reliable command line or GUI tool (ldp) to configure perms just the way I want and need? Actually I don care even if I have to use a series of command line apps. I dont care how complex it is/willbe right now. I just want something that works. And I want the tool from MSFT. For free ;0) Please! Cheers M@ P.S. thanks once again for reading, for escalating, for laughing, for educating , the kind words, hugs Control-H,Control-H,Control-H,Control-H,Control-H, etc... On 7/25/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I guess Matheesha's original question has been answered as good as it can for now with the information given. I just quickly want to comment on the 3rd party tool aspect joe is mentioning below - naturally, before spending considerable money on the tools, you'd need to test if they do what you want them to do in the first place. What I've found from many years of leveraging and checking different ACLing tools is that they also just go so far... I've had various different customer requests, which could not be achieved with the tools, but could be achieved with the native ACLs (mostly talking AD here). After getting over the hurdles of the basics, scripting quickly becomes your friend. I am not saying that 3rd party tools aren't quite useful for general ACLing stuff - it's when your own security model is complex, the tools will often not be able to help you reach your goal. Often this is a result of the complex ACLing rules build by MSFT themselves. Very hard for a developer to keep up with all changes (think of all the changes in Win2003 compared to 2000 and then with Win2003 SP1) and to understand the plethora of rules, especially when it comes to combining specific ACLing settings set at totally different places in the directory. A great example for this are various options to controlling delegation of password settings (I've written this up internally and for my upcoming Windows security book, as joe had been pointed at in his other reply). Win2003 provides three new not so well known extended rights, which allow domain admins to control which delegated admin can change critical password attributes on user accounts: * Enable-Per-User-Reversibly-Encrypted-Password * Unexpire-Password * Update-Password-Not-Required-Bit The challenge: these extended rights are set at the domain level, while other permissions to control which delegated admin can do what in an OU (e.g. create and manage users) are typically set at the OU level. So if you give a delegated admin full control over users, he would for example not be able to set the Password never expires and the Store password using reversible encryption options on the user accounts he is allowed to fully control, UNLESS he is ALSO granted the appropriate extended right at the root of your domain (Unexpire-Password and Enable-Per-User-Reversibly-Encrypted-Password in this example). This is certainly challenging for any domain admininstrator and moreso for 3rd party ACLing tools. Realize that by default the three extended rights I have mentioned above are granted to Authenticated Users, which means that any delegated admin who is also granted the rights to control the account restrictions of a user can set the respective password options. As these are rather sensible settings though, I'd rather disable any delegated admin from setting them (which is why the extended rights have been added to Win2003 in the first place). If you have different admins allowed to create users, just check out your domains and see how many users are configured with the password never expires flag - you will quickly understand what I mean. But again: it is very tough for 3rd party tools to remove default rights for you
RE: [ActiveDir] ldp in ADAM-SP1
infrastructure to attempt to administer perms for 20,000 users plus many OUs used to organise users based on the business unit (at least a dozen in each geographical hub) they work in and the site (we have more than a 40 geographical hubs and 1000 satellite sites) they are located at. Different levels of data admin roles. I would like to get this right to a large extent from the moment go. Admittedly it may not be big as in Fortune 5 ADs. But its the biggest I've had the privilege to design and support. I figured if I test this using the case study as a lab, I will get a good feel of whats involved in my lower level design. I am getting a little miffed when I have to swap between several tools to do what I need to do. There is just so many buts and ifs. You can do this but you cant do this. To do this use this. For this use that. And then try this. If all else fails script I admit I was ranting a bit when asking why is this named and like such and the discrepencies in the docs and syntax help of command line tools. My sincere apologies for been anal. Is it too much to ask, to have at the very least a reliable command line or GUI tool (ldp) to configure perms just the way I want and need? Actually I don care even if I have to use a series of command line apps. I dont care how complex it is/willbe right now. I just want something that works. And I want the tool from MSFT. For free ;0) Please! Cheers M@ P.S. thanks once again for reading, for escalating, for laughing, for educating , the kind words, hugs Control-H,Control-H,Control-H,Control-H,Control-H, etc... On 7/25/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I guess Matheesha's original question has been answered as good as it can for now with the information given. I just quickly want to comment on the 3rd party tool aspect joe is mentioning below - naturally, before spending considerable money on the tools, you'd need to test if they do what you want them to do in the first place. What I've found from many years of leveraging and checking different ACLing tools is that they also just go so far... I've had various different customer requests, which could not be achieved with the tools, but could be achieved with the native ACLs (mostly talking AD here). After getting over the hurdles of the basics, scripting quickly becomes your friend. I am not saying that 3rd party tools aren't quite useful for general ACLing stuff - it's when your own security model is complex, the tools will often not be able to help you reach your goal. Often this is a result of the complex ACLing rules build by MSFT themselves. Very hard for a developer to keep up with all changes (think of all the changes in Win2003 compared to 2000 and then with Win2003 SP1) and to understand the plethora of rules, especially when it comes to combining specific ACLing settings set at totally different places in the directory. A great example for this are various options to controlling delegation of password settings (I've written this up internally and for my upcoming Windows security book, as joe had been pointed at in his other reply). Win2003 provides three new not so well known extended rights, which allow domain admins to control which delegated admin can change critical password attributes on user accounts: * Enable-Per-User-Reversibly-Encrypted-Password * Unexpire-Password * Update-Password-Not-Required-Bit The challenge: these extended rights are set at the domain level, while other permissions to control which delegated admin can do what in an OU (e.g. create and manage users) are typically set at the OU level. So if you give a delegated admin full control over users, he would for example not be able to set the Password never expires and the Store password using reversible encryption options on the user accounts he is allowed to fully control, UNLESS he is ALSO granted the appropriate extended right at the root of your domain (Unexpire-Password and Enable-Per-User-Reversibly-Encrypted-Password in this example). This is certainly challenging for any domain admininstrator and moreso for 3rd party ACLing tools. Realize that by default the three extended rights I have mentioned above are granted to Authenticated Users, which means that any delegated admin who is also granted the rights to control the account restrictions of a user can set the respective password options. As these are rather sensible settings though, I'd rather disable any delegated admin from setting them (which is why the extended rights have been added to Win2003 in the first place). If you have different admins allowed to create users, just check out your domains and see how many users are configured with the password never expires flag - you will quickly understand what I mean
RE: [ActiveDir] Have you built an R2 Forest?
hehe, yep I've seen that (the difference of the Schema.ini files; i.e. missing entry for the tombstonelifetime property) but didn't think too much of it because for now I've only had to handle upgrading from Win2000 or 2003 to R2 where the Schema.ini doesn't play a role. It is "only" used to populate a blank schema at the time that you create a new AD forest - and yes, this means that your tombstone lifetime wouln't match that of other Win2003 forests that were created from a DC that had SP1 applied to it... I agree, not very nice, but easily fixed as you describe. Personally, I don't think too much of the fact that the tombstonelifetime was increased to 180 days in SP1 anyways. This was done to avoid issues for companies with a badly managed AD- I would generally much prefer to adjust the value to what is appropriate for a company's backup recovery strategy. And this usually doesn't mean that you need to keep the "garbage" in your AD for 1/2 a year... Granted, it's the inconsistency here with which MSFT has done the update of the schema.ini files which is not so nice - but the rules are pretty clear on how tombstone lifetime can be evaluated by an admin: if the attribute on the Directory Services object (tombstoneLifetime ð CN=DirectoryService,CN=WindowsNT,CN=Services,CN=Configuration,DC=MyRootDomain) shows NOT SET, then it't the "original" default tombstone lifetime of 60 days. Else it's whatever number of days has been set either by the DCPROMO routine writing a specific value into the attributewhen creating a new forest,or by an admin changing the value to whatever is appropriate. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Monday, July 24, 2006 1:50 AMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Have you built an R2 Forest? If so... you may want to peek at http://blog.joeware.net/2006/07/23/484/ entitled "R2 tombstoneLifetime boo boo" -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
RE: [ActiveDir] Have you built an R2 Forest?
just to be clear: step 3 (R2 adprep) is NOT needed at all if you build a new forest - your not doing an upgrade here. Whenever you do an upgrade, you do NOT change the TSL. The documentation is wrong as the TSL is always the hardcoded value of 60, if the value is "not set". If you've created a new forest from an SP1 DC it would be overwritten with an explicit value of 180. This is what we'd also expect on R2, but due to an incomplete schema.ini file (which is missing the explicit setting of the TSL value to 180), a new R2 forest also has this value "not set" = 60. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: Monday, July 24, 2006 4:38 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Have you built an R2 Forest? inline From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Monday, July 24, 2006 16:01To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Have you built an R2 Forest? Thanks for this joe. That doc is more than bad - it's plain wrong :( Justtofurtherclarify: 1. If I build a new R2 forest, I should expect a blank TSL - which implies a 60 days TSL. Correct?[JdAP says:]YES (but it should be 180 days!) 2. All I need to do to 'fix' this 'issue' is to amend the TSL via admod or adsiedit or whatever... ? Correct?[JdAP says:]YES, ADDTHE180 VALUE 3. I only need to run the R2 adprep once per forest. [Stated for completeness][JdAP says:]YES 4. Do I need to run the R2 setup on each machine I build? Will this process revert the TSL back to 'not set'?[JdAP says:](1) ONLY IF YOU NEED THE R2 STUFF, (2) NO I'm trying to understand the issue below but also how it is caused and how it may be caused again.[JdAP says:]WRONG SCHEMA.INION THE MEDIA neil PS I agree re R2 and its value above and beyond SP1. But what a great marketing ploy :) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: 24 July 2006 14:44To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Have you built an R2 Forest? This all started due to bad documentation on http://technet2.microsoft.com/WindowsServer/en/library/f3df8a52-81ea-4a1d-9823-4e51fbd3422a1033.mspx?mfr=true which states Note the value in the Value column. If the value is not set, the default value is in effect as follows: On a domain controller in a forest that was created on a domain controller running WindowsServer2003 with Service Pack1 (SP1), the default value is 180days. On a domain controller in a forest that was created on a domain controller running Windows2000Server or WindowsServer2003, the default value is 60days. which was confusing a customer. Then after I explained about how 60 days is hardcoded and 180 days was a schema.ini fix he further indicated that he wasn't seeing this in an R2 forest hence his original question. The test R2 forests I have built I never checked TSL, just assumed it was 180 and normally I don't built R2 machines because I really don't much care about R2, SP1 is far more important for the stuff I play with. I mean really, how many people verify the TSL of their forest versus just assuming it was whatever MSFT or someone representing MSFT said it should be. I know I have told a ton of people that after SP1 the value is180 and I want to make sure I tell all of those same people that it really isn't in R2. My concern is for people who have put an R2 forest out there and are under the running assumption that they now have a 180 day TSL and make some decision based on it (yes, it is ok if our DC sits on the doc in Mexican customs for 3 months (this is a real example) because we have a 180 day TSL) and learn after the fact that it was incorrect. It also has backup/restore implications. Hopefully the above docs will be corrected and the word will seep out and people will be aware.This is one of those things where if you find it out after you already had an incident you will be like, WTF Microsoft. It also makes me wonder if there is anything else that was regressed... joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, GuidoSent: Monday, July 24, 2006 2:12 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Have you built an R2 Forest? hehe, yep I've seen that (the difference of the Schema.ini files; i.e. missing entry for the tombstonelifetime property) but didn't think too much of it because for now I've only had to handle upgrading from Win2000 or 2003 to R2 where the Schema.ini doesn't play a role. It is "only" used
RE: [ActiveDir] Raid 1 tangent -- Vendor Domain
I don't have a lot of experience yet with x64 DCs but my gut says that assuming you have enough RAM to cache the entire DIT and you aren't constantly rebooting the DC or doing things that force the cache to be trimmed, the disk subsystem is really only going to be important for writes (which we have already said aren't really all that much of what AD is doing) and the initial caching of the DIT. The key as joe pointed out nicely in his short note below is the size of your DIT and if it can be cached in memory by the DC. For large AD infrastructures, this is where the benefit of 64-bit DCs (either x64 or Itanium, with Itanium usually being an overkill for most AD environments). A 32-bit OS has 4GB virtual memory available that it can directly address usually split evenly between user/application memory and kernel memory, i.e. 2GB each. Win2000 DCs can use a max of approx. 512MB for the LSASS (AD) process, which is about how much of the DIT it can cache. LSASS has already been improved quite a bit for Win2003 DC, which can cache up to 1.5GB of the normal virtual address space available to the DC. Using the /3GB switch you can force the kernel to use less memory (1GB), so that you have up to 3GB available for your applications - note that apps that leverage kernel memory (such as IIS) are hurt by using this switch. For Win2000 DCs (Advanced Server only) you can use the /3GB switch to increase the DIT cache to 1GB. For Win2003 DCs (Standard and Enterprise) it's up to 2.7GB. The 32-bit x86 systems that use more than 4 GB of physical memory cannot directly address this memory - instead they leverge a technology called Physical Addressing Extensions (PAE). This is a segmented memory model that requires the use of Address Windowing Extensions (AWE) allowing the memory beyond 4 GB to be swapped in and out of an AWE window that exists in the first 4 GB of memory. These memory management technologies do cost expensive CPU cycles and are not nearly as efficient as direct 64-bit addressing. With 64-bit addressing there is no need for a /3GB switch or other memory extension techniques, as you can (theoretically) *directly* address up to 2^64 bits of memory, which is equal to 16 exa-bites (=16 billion GB). Naturally, there isn't any HW available yet to host this much memory. But we can soon expect standard server systems that are capable of handling a few hundred GBs of memory - nothing you should need anytime soon for your AD. Microsofts's support for physical memory for it's Win2003 64bit OSs is thus limited as well: - 32GB for the x64 Standard Edition - 1TB for the x64 and Itanium Enterprise and Datacenter editions So, even with a Win2003 x64 Standard Edition DC you can directly address up to 32GB of memory in your servers - the available physical memory will be split up evenly into user and kernel memory, meaning that with 32GB you'd have 16GB available for applications (and with a pure DC this would give you roughly 14GB for caching your AD DIT). Not many will need it for their ADs, but with the Enterprise or Datacenter editions you can cache approx. up to 460GB of your DIT in memory... We've done quite extensive internal tests at HP to evaluate how 64bit DCs would do performancewise as GCs (for Exchange and authentication) and found that a single 64bit DC (with sufficient RAM to cache our whole DIT, which is almost 9GB in size), could easily replace 3-4 of our current 32bit GCs. Disc configuration hardly played a role for these performance gains. Naturally we have the greatest ratio for consolidation in our largest datacenters. I can only suggest everyone to have a closer look at using 64bit for their DCs as well - it will be very benefitial down the road. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, July 22, 2006 6:49 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Raid 1 tangent -- Vendor Domain Mirrors don't scale. Microsoft's deployment doc mostly just talks about using mirrors (small nod to RAID 10/0+1) so everyone thinks that they should build their Corporate DCs on mirrors, usually 3 - OS, Logs, and DIT. Very few people if anyone would build a corporate Exchange Server on mirrors... Why not? The DB is the same under both of them... What is critical to Exchange? IOPS and that means spindles. If something is really beating on AD and the entire DIT can't be cached, IOPS are critical to AD as well. The main difference is that AD is mostly random read and Exchange is heavy writing and reading. The exception to this is the edge case of Eric's big DIT[1] in which he dumped 2TB of data into AD in a month at which point he did something that few people see, pushed the IOPS on the log drive through the roof. In a smaller environment (very low thousands), or for a low use DC (small WAN site), or a DC with a DIT fully cached a RAID-1 drive for DIT will probably be sufficient, you will note that the only numbers
RE: [ActiveDir] 64bit Windows
Renaming the thead due to change of focus topic I've been doing quite a bit with my own 64bit notebook (using WinXP x64) in the past few weeks and I do have to say that there are plenty of little surprises. Many of which don't play a role for servers, which are used with a much lesser range of applications and drivers (usually no issues with high res video; WLAN; bluetooth etc.). I was actually more successful to get the right drivers for WinXPx64 than for VISTAx64, which is why I stuck with WinXP for now (this will change soon, as Vendors pick up their support for Vista and any driver will have to be available as 32 and 64bit to be Vista ready). But it's not only drivers, it's also some 32bit applications that - although they don't have a driver dependency (which must all be 64bit)- simply refuse to run in the WOW64 instance (a 32-bit Windows instance on in a Win x64 OS). Have to say that the most important 32bit apps (such as MS Office 2003) and naturally all 64bit apps do run though without issues.And I can work around most of the other 32-bit problems by leveraging a 32-bit WinXP VM on the same box (not ideal, but better than two machines). So a lot of testing is required either for deployment of 64-bit clients (which I'd rather do with Vista when released) or even with 64-bit Terminal Servers that are used to host office applications for users (generally a great idea, as you have plenty of more virtual memory available for hosting many more users per TS). See my other note on 64-bit for DCsin the "Raid 1 tangent -- Vendor Domain" thread with many more details on the difference of memory handling between the two worlds. 64bit is certainly the right way to go for most larger AD deployments. I'd love to hear about other's experience with 64-bit Windows - how are you leveraging it and what were the problems you've been running into...? What were your solutionsor workarounds? /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt HargravesSent: Sunday, July 23, 2006 5:26 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Raid 1 tangent -- Vendor Domain It's not that big of a deal for client software (last message) On 7/23/06, Matt Hargraves [EMAIL PROTECTED] wrote: That being said wait on 64-bits for the client side until you know, unequivocably, that all of the software that your clients need is supported and stable on a 64-bit OS. The performance boost isn't that big of a deal, just to be honest. On 7/23/06, Matt Hargraves [EMAIL PROTECTED] wrote: Just as an FYI: I've seen 64-bit DCs run and I have one thing that I can recommend to everyone:Go 64-bits as soon as possible. There are hundreds of benefits on the server side when going 64-bits, whether it's Exchange (yay for 2007) or your DCs, the performance level is just staggering compared to a 32-bit OS. All your former large application limitations just kinda disappear, unless it's an application-based limitation. No 3GB limitation on the application memory size, no paged pool memory limitation for connections (this hits Exchange first) It's like you're crippling your hardware by staying 32-bits nowadays if you don't have to. On 7/22/06, joe [EMAIL PROTECTED] wrote: That's a command line guy for you...:o)The thing is that I type in a very odd way two, my whole right hand just oneor two fingers from my left hand. People tend to get a bit confused whenthey see me type. joe--O'Reilly Active Directory Third Edition -http://www.joeware.net/win/ad3e.htm-Original Message-From: [EMAIL PROTECTED][mailto: [EMAIL PROTECTED]] On Behalf Of Kevin GentSent: Saturday, July 22, 2006 7:29 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Raid 1 tangent -- Vendor Domainjoe,you must type really, really fast- Original Message -From: "Albert Duro" [EMAIL PROTECTED]To: ActiveDir@mail.activedir.orgSent: Saturday, July 22, 2006 7:06 PMSubject: Re: [ActiveDir] Raid 1 tangent -- Vendor Domain no debate from me.I was just asking.Thank you for the lesson. - Original Message - From: "joe" [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Saturday, July 22, 2006 9:48 AM Subject: RE: [ActiveDir] Raid 1 tangent -- Vendor Domain Mirrors don't scale. Microsoft's deployment doc mostly just talks about using mirrors (small nod to RAID 10/0+1) so everyone thinks that they should build their Corporate DCs on mirrors, usually 3 - OS, Logs, and DIT. Very few people if anyone would build a corporate Exchange Server on mirrors... Why not? The DB is the same under both of them... What is critical to Exchange? IOPS and that means spindles. If something is
RE: [ActiveDir] Domain Trusts.
because the objects that need to go in that domain really do need to get out of our current user environment. Matt, this doesn't yet sound to me like administrative isolation. Really depends on what you mean with "user environment". If these objects should not be administered by the same admins, then it's likely a case for isolation. If the objects should not be accessible for the normal users (incl. the servers or other resources that the objects represent), then it's a case for ACLing and configuring your AD and GPOs. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt HargravesSent: Sunday, July 23, 2006 5:10 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Domain Trusts. Basically we're looking at creating a resource domain because the objects that need to go in that domain really do need to get out of our current user environment.But if you can't move items into a forest without having an automatic 2-way transitive trust, then we might need to just go with a separate forest. We're looking at other options internally and it's possible that we may not need security isolation for these other domains. Time will tell. You've all been very helpful, thank you. Hopefully MS will state in their documentation at some point in time that these trusts can't be altered so that other people don't have to go "I know it's automatically created when I create the object, but what can I do with the trust" any more :) On 7/22/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: you might want to describe to us what your actual goal is for creating a non-fully trusted domain in your AD forst. Maybe you can reach a similar goal by using the fairly powerful capabilities in AD to delegate administration of objects within a domain. You can also use these features to hide specific parts of AD from the rest of the organization and thus create a "semi-isolated" units within a single AD domain. Note that there is no way to fully isolate any objects within a domain or forest from domain or enterprise admins - if you do need full administrative isolation, you have to create multiple forests. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Almeida Pinto, Jorge deSent: Saturday, July 22, 2006 12:45 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Domain Trusts. 1-yep 2-yep Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto Senior Infrastructure Consultant MVP Windows Server- Directory Services LogicaCMG Nederland B.V. (BU RTINC Eindhoven) ( Tel : +31-(0)40-29.57.777 ( Mobile: +31-(0)6-26.26.62.80 * E-mail: see sender address From: [EMAIL PROTECTED] on behalf of Matt HargravesSent: Sat 2006-07-22 00:35To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Domain Trusts. So basically there's no way to have a domain in a forest that doesn't fully trust every other domain in the forest?The only way to have a non 2-way trust is to make a separate forest?
RE: [ActiveDir] 64bit Windows
thanks Susan - yep, I've felt the pain with VPN support myself - mine is not related to ISA 2004 though. As mentioned in my other reply, can you be a bit more specific on the beancounter (financial?) apps. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, July 23, 2006 6:52 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] 64bit Windows You haven't met beancounter apps have you? Many of them will not function. Yes, it's a big deal. When even Microsoft's own ISA 2004 doesn't have a released 64 bit client released for a 64 bit Windows and you have to set them up as securenat clients. adoption by vendors has not occurred. Grillenmeier, Guido wrote: /Renaming the thead due to change of focus topic/ I've been doing quite a bit with my own 64bit notebook (using WinXP x64) in the past few weeks and I do have to say that there are plenty of little surprises. Many of which don't play a role for servers, which are used with a much lesser range of applications and drivers (usually no issues with high res video; WLAN; bluetooth etc.). I was actually more successful to get the right drivers for WinXPx64 than for VISTAx64, which is why I stuck with WinXP for now (this will change soon, as Vendors pick up their support for Vista and any driver will have to be available as 32 and 64bit to be Vista ready). But it's not only drivers, it's also some 32bit applications that - although they don't have a driver dependency (which must all be 64bit) - simply refuse to run in the WOW64 instance (a 32-bit Windows instance on in a Win x64 OS). Have to say that the most important 32bit apps (such as MS Office 2003) and naturally all 64bit apps do run though without issues. And I can work around most of the other 32-bit problems by leveraging a 32-bit WinXP VM on the same box (not ideal, but better than two machines). So a lot of testing is required either for deployment of 64-bit clients (which I'd rather do with Vista when released) or even with 64-bit Terminal Servers that are used to host office applications for users (generally a great idea, as you have plenty of more virtual memory available for hosting many more users per TS). See my other note on 64-bit for DCs in the Raid 1 tangent -- Vendor Domain thread with many more details on the difference of memory handling between the two worlds. 64bit is certainly the right way to go for most larger AD deployments. I'd love to hear about other's experience with 64-bit Windows - how are you leveraging it and what were the problems you've been running into...? What were your solutions or workarounds? /Guido *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Matt Hargraves *Sent:* Sunday, July 23, 2006 5:26 PM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] Raid 1 tangent -- Vendor Domain It's not that big of a deal for client software (last message) On 7/23/06, *Matt Hargraves* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: That being said wait on 64-bits for the client side until you know, unequivocably, that all of the software that your clients need is supported and stable on a 64-bit OS. The performance boost isn't that big of a deal, just to be honest. On 7/23/06, *Matt Hargraves* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Just as an FYI: I've seen 64-bit DCs run and I have one thing that I can recommend to everyone: Go 64-bits as soon as possible. There are hundreds of benefits on the server side when going 64-bits, whether it's Exchange (yay for 2007) or your DCs, the performance level is just staggering compared to a 32-bit OS. All your former large application limitations just kinda disappear, unless it's an application-based limitation. No 3GB limitation on the application memory size, no paged pool memory limitation for connections (this hits Exchange first) It's like you're crippling your hardware by staying 32-bits nowadays if you don't have to. On 7/22/06, *joe* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: That's a command line guy for you... :o) The thing is that I type in a very odd way two, my whole right hand just one or two fingers from my left hand. People tend to get a bit confused when they see me type. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] mailto:[EMAIL
RE: [ActiveDir] Domain Trusts.
Matt, I'm quite aware of the token limitations in AD (and the lovely attack vectors around this "feature") - however, creating a separate domain for this reason would fall under administrative isolation, which is not how you've phrased your previous reply. So I'm a little but puzzled as to what your real goal is. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt HargravesSent: Sunday, July 23, 2006 7:01 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Domain Trusts. Go to google, type in "Token limitation" and click on the first item... On 7/23/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: because the objects that need to go in that domain really do need to get out of our current user environment. Matt, this doesn't yet sound to me like administrative isolation. Really depends on what you mean with "user environment". If these objects should not be administered by the same admins, then it's likely a case for isolation. If the objects should not be accessible for the normal users (incl. the servers or other resources that the objects represent), then it's a case for ACLing and configuring your AD and GPOs. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt HargravesSent: Sunday, July 23, 2006 5:10 PM To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Domain Trusts. Basically we're looking at creating a resource domain because the objects that need to go in that domain really do need to get out of our current user environment.But if you can't move items into a forest without having an automatic 2-way transitive trust, then we might need to just go with a separate forest. We're looking at other options internally and it's possible that we may not need security isolation for these other domains. Time will tell. You've all been very helpful, thank you. Hopefully MS will state in their documentation at some point in time that these trusts can't be altered so that other people don't have to go "I know it's automatically created when I create the object, but what can I do with the trust" any more :) On 7/22/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: you might want to describe to us what your actual goal is for creating a non-fully trusted domain in your AD forst. Maybe you can reach a similar goal by using the fairly powerful capabilities in AD to delegate administration of objects within a domain. You can also use these features to hide specific parts of AD from the rest of the organization and thus create a "semi-isolated" units within a single AD domain. Note that there is no way to fully isolate any objects within a domain or forest from domain or enterprise admins - if you do need full administrative isolation, you have to create multiple forests. /Guido From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Almeida Pinto, Jorge deSent: Saturday, July 22, 2006 12:45 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Domain Trusts. 1-yep 2-yep Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto Senior Infrastructure Consultant MVP Windows Server- Directory Services LogicaCMG Nederland B.V. (BU RTINC Eindhoven) ( Tel : +31-(0)40-29.57.777 ( Mobile: +31-(0)6-26.26.62.80 * E-mail: see sender address From: [EMAIL PROTECTED] on behalf of Matt HargravesSent: Sat 2006-07-22 00:35To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Domain Trusts. So basically there's no way to have a domain in a forest that doesn't fully trust every other domain in the forest?The only way to have a non 2-way trust is to make a separate forest?
RE: [ActiveDir] Vendor Domain
Will the application run off of an ADAM instance instead of a full blown forest? That was going through my mind as well - why would the vendor want to use a NOS AD for his application? Again, there must be some reason for this. joe makes great points rgd. the support issues of an application which is fully integrated into the NOS AD, but is managed by a different team - possibly the vendor himself. So knowledge about the planned support model will certainly help to discuss justification of a separate forest. Clearly, that should include management of that extra forest itself (who is responsible for backing up that forest and ensuring operation of the DCs etc.). /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, July 20, 2006 10:55 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Vendor Domain My first reaction is that that is pretty nebulous and hazy. I don't think they can compare whatever it is they do to a respirator and have validity, I think that would be talking apples and olive pits. Overall it sounds like a move to reduce support and troubleshooting costs by having a known fixed environment in which their app will run. It could even mean that they have bad decisions (and coding) in the software itself that has hard requirements to that specific layout so they don't have to code for a more generic setup. Certainly the concern that AD may not be stable is a valid one from a vendor doing managed service support standpoint as it is something I have encountered in the field myself.More environments than not that I have walked into to deploy Exchange the AD folks thought AD was perfectly fine and were surprised when Exchange dragged their DCs under water and I have to go through their design and figure out what exactly isn't optimal (hint usually the disk subsystems - stop using mirrors damnit).But if the customer is willing to accept that risk as a caveat to the support model then the vendor should be able to support it. This can and usually should have some level of impact on costing and possibly support levels and penalties (if they exist). It is cheaper to run support on a fixed known setup than it is to support something you didn't design and can't exercise control over. You as a customer would need to accept that as well. But it really comes back to whether the product will work in a generic environment at all and if the vendor is willing to put in the time to figure out their exposure and write the contract(and bill) to suitably cover for it. Taking this back to an Exchange example which is more familiar to many folks. Take the example whereyou want email and you bring someone in to create and run an Exchange service for you. You aren't managing or supporting it, it is all them, you simply give them the requirements.If they have a cookie cutter separate domain/forest solution it is something they have worked out and tested and understand and can best support. In general I think it is better for you and think it is good for you to strongly considerallowing them to run it that way because of the issues with Exchange and the resulting administration mess. It is tough to fight it because there aren't a lot of options outside of Exchange with the features people want... If you have strong feelings against that separate forestand wantthe vendorto forgo their own design, which does happen, they can and usually willrun it from your forest however you havegot to expect cost increases.You are basically telling the respirator company (to use that bad analogy) that you want the respirator to work in an entirely different way than the product you picked out of the catalog. The prices increases are to cover real costs incurred by the vendorto cover a changed support model and cover for the extra design work that they would need to be involved into support your environment.In addition, you would need toaccept the caveats on service that they may need to put into place to protect themselves from lawsuits that are actually the fault of something they don't control. An example would beany issues that end up having a root cause back in theAD that you control releases them from SLA penalties and allows them to charge back costs associated with it. A specific example is say where you have company A running a mail service for you out of your directory and you allow local site admins to have extensive control over their users and one of the admins decided to give himself a 10GB quota and then uses it and kills the free space on the Exchange server causing the vendor to scramble resources to cover for the resulting issues. That absolutely needs to be charged back to the company and not the vendor. Even if you have separate groups in the same company running AD and Exchange those are things that get fights going over because the Exchange team is budgeted to cover Exchange issues and the AD
RE: [ActiveDir] Domain Trusts.
you might want to describe to us what your actual goal is for creating a non-fully trusted domain in your AD forst. Maybe you can reach a similar goal by using the fairly powerful capabilities in AD to delegate administration of objects within a domain. You can also use these features to hide specific parts of AD from the rest of the organization and thus create a "semi-isolated" units within a single AD domain. Note that there is no way to fully isolate any objects within a domain or forest from domain or enterprise admins - if you do need full administrative isolation, you have to create multiple forests. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: Saturday, July 22, 2006 12:45 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Domain Trusts. 1-yep 2-yep Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto Senior Infrastructure Consultant MVP Windows Server- Directory Services LogicaCMG Nederland B.V. (BU RTINC Eindhoven) (Tel : +31-(0)40-29.57.777 (Mobile: +31-(0)6-26.26.62.80 * E-mail: see sender address From: [EMAIL PROTECTED] on behalf of Matt HargravesSent: Sat 2006-07-22 00:35To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Domain Trusts. So basically there's no way to have a domain in a forest that doesn't fully trust every other domain in the forest?The only way to have a non 2-way trust is to make a separate forest?
RE: [ActiveDir] Vendor Domain
I think everyone would be conceptually opposed - would be good to hear the vendor's reasoning for this. What does the app do? What benefit do you have from running their app in a speparate (single domain) forest? I can think of many downsides, but if the app is supposed to protect really sensitive data (isolation scenario), this may potentially be the reason for them to demand a separate forest. Certainly not, if the same folks manage both forests though... So pls. aks them for more details - doesn't hurt to understand their thinking. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Figueroa, JohnnySent: Wednesday, July 19, 2006 8:09 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Vendor Domain We are a 2003 Forest with an empty root domain and a single child domain. We have a vendor looking to bring in a product that utilizes its own domain and has a one way trust to our domain. I do not know anything about the product yet but I am almost conceptually opposed to these vendor domains. I am looking for pros and cons... really ammunition to say no. Thanks Johnny FigueroaSupervisor Network Operations SupportNetwork ServicesBanner HealthVoice (602) 747-4195Fax (602) 747-4406WARNING: This message, and any attachments, are intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or employee/agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of the communication is strictly prohibited. If you receive this communication in error, please notify us immediately
RE: [ActiveDir] Forest trust - domain drop down list
yes Tony, this is standard behaviour - you'll only see domains that are directly trusted. Trust type doesn't matter. Even though a forest trust will be transitive to all child domains by default, you'll have to use UPN to authenticate to a child domain. Which is another reason why empty placeholder roots don't really make an administrator's life easier... The challenges continue for viewing objects of a trusted child-domain accross a forest trust in the object picker - afaik, it will also just show you the root domain (but you can find objects in the child by searching the GC...) if you put in a normal external trust between your DomB and the DomA2, you'll lose the benefit of kerberos authentication from your forest trust (when choosing DomA2 in the logon window). If that's ok for you, this is a solution, but then you might as well get rid of the forest trust... /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Freitag, 14. Juli 2006 05:54 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Forest trust - domain drop down list Here's the scenario Forest trust between ForestA and ForestB. ForestA has two domains DomA1 (placeholder root) and DomA2 ForestB has one domain DomB Users from DomA2 sometimes log into DomB member machines. DomA2 is not shown in the drop-down list of domain names in the login dialog. DomA1 is shown. Users from DomB sometimes log into DomA2 member machines. DomB is not shown in the drop-down list of domain names ni the login dialog. Is it normal behaviour for the drop-down list not to show all the domains with trusts (including those that are transitive via the forest trust)? If so, is there any way to change the behaviour? The users can obviously login using UPN, but they are not used to doing this and there is talk of putting in an explicit domain trust between DomA2 and DomB simply to get around this. Ugh. Tony List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
I'd have to do some more digging as to *why* the duplicate app-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFM feature to rollout the DCs. But prior to SP1 you couldn't add the application partitions to the dcpromo process (IFM in SP1 now offers an the options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created the DomainDnsZones app-partiontion right after their first reboot, causing some interesting challenges. Agree they should have contacted the DN master - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition. Anyways, to avoid similar issues, SP1 ensures that AD completes the replication with one partner prior to allowing the DNS service to read it's records and to register anything. This is actually similar to the change that was done with either Win2000 SP2 or SP3 to avoid DCs to advertise their GC status prior to finishing a replication cycle with another GC or one DC of every domain in their site. The challenge here is that you get into a race-condition when using the DC itself as the primary DNS server - ofcourse this will still work, but you have to wait for many more timeouts during the reboot of the AD DC: for every DNS query prior to a successful replication, the DC will first try to query it's own DNS server and won't use the secondary until a DNS timeout... I've seen the boot-times of DCs go up to 10 and more minutes. This can usually be fixed by setting the primary DNS server of the DC to another DNS server (naturally won't help, if both are booted at once - consider this during your DR planning...) /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams Sent: Freitag, 14. Juli 2006 12:33 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? I can't see how you can get a duplicate NDNC as the creation of such objects is targetted at the DN master. The DN master will check the existing crossRefs and stop this happening, as we can't rely on the DS stopping it as the RDN is different for each NDNC (unless they've used well-known GUIDs for the DNS NCs?). Although the behaviour you speak of is new to me, and another one of those slight, interesting changes, so thanks for that. Can you elaborate on this new behaviour? What, exactly, happens and in what order? --Paul - Original Message - From: Grillenmeier, Guido [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, July 13, 2006 6:52 PM Subject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? note that DNS startup behavious changes with SP1, which is another reason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until it has successfully replicated with one of it's replication partners. This is to avoid false or duplicate registration of records (or even duplicate creation of the application partitions). As such, with SP1 it's better to point your DCs to a replication partner as a primary DNS and to self as a secondary. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Donnerstag, 13. Juli 2006 17:02 To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Hi Al I did want to throw in a personl experience I had with W2K3 that validates the Point your DNS server to a replication partner theory. I did see in one environment where every DC had DNS and the msdcs partition was a forest partition. An unfortunate DNS scavenge was done deleting some of the GUID records in the MSCDCS partition. Replication started to fail shortly after that and the missing GUIDs were discovered. The netlogon service was restarted to make the DCs re-register but of course they re-registered the GUID on themselves. They could find themselves but not their replication partners. The replication partners could find them but not themeselves. When the DCs were set to point to a hub replication partner for primary and themselves as secondary the problem went away - the netlogon service was restarted, the GUIDs registered on the central DNS server, the spokes did the lookup for replication parnters on the hub site DC and eventually things started working again. This was pre - SP1 so this may not be a problem anymore, but after that experience I have seen value in doing the DNS configuration so that the DCs all point to the hub first and themselves second. I have not seen any problems for the DC itself when
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
there was no need to check on this issue again - with SP1 it doesn't happen ;-) I'm sure there were several pre-SP1 fixes targeted at this issue and were then integrated into SP1. but rgd. the startup behaviour of DNS in SP1, I'm rather sure that's unchanged at this point. Would be happy to be corrected. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Freitag, 14. Juli 2006 19:46To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Guido, have you checked this lately? I know there were several changes to that behavior in several revs IIRC. The problems you describe were better than a challenge, as I recall. they had a tenedancy to wreak havoc with integrated dns zones when a dc would come up and create a new zone and then replicate that. There were several fixes related though and that behavior might have changed several times. On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I'd have to do some more digging as to *why* the duplicateapp-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFMfeature to rollout the DCs. But prior to SP1 you couldn't add theapplication partitions to the dcpromo process (IFM in SP1 now offers anthe options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created theDomainDnsZones app-partiontion right after their first reboot, causingsome interesting challenges. Agree they should have contacted the DNmaster - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition.Anyways, to avoid similar issues, SP1 ensures that AD completes thereplication with one partner prior to allowing the DNS service to readit's records and to register anything. This is actually similar to the change that was done with either Win2000 SP2 or SP3 to avoid DCs toadvertise their GC status prior to finishing a replication cycle withanother GC or one DC of every domain in their site.The challenge here is that you get into a "race-condition" when using the DC itself as the primary DNS server - ofcourse this will still work,but you have to wait for many more timeouts during the reboot of the ADDC: for every DNS query prior to a successful replication, the DC will first try to query it's own DNS server and won't use the secondary untila DNS timeout...I've seen the boot-times of DCs go up to 10 and moreminutes.This can usually be fixed by setting the primary DNS server of the DC to another DNS server (naturally won't help, if both are bootedat once - consider this during your DR planning...)/Guido-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Paul WilliamsSent: Freitag, 14. Juli 2006 12:33To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itselfas the preferred DNS server...always?I can't see how you can get a duplicate NDNC as the creation of such objectsis targetted at the DN master. The DN master will check the existingcrossRefs and stop this happening, as we can't rely on the DS stoppingit asthe RDN is different for each NDNC (unless they've used "well-known" GUIDsfor the DNS NCs?).Although the behaviour you speak of is new to me, and another one ofthoseslight, interesting changes, so thanks for that.Can you elaborate on this new behaviour?What, exactly, happens and in whatorder?--Paul- Original Message -From: "Grillenmeier, Guido" [EMAIL PROTECTED]To: ActiveDir@mail.activedir.orgSent: Thursday, July 13, 2006 6:52 PMSubject: RE: [ActiveDir] Always point a DC with DNS installed to itselfasthe preferred DNS server...always? note that DNS startup behavious changes with SP1, which is another reason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until ithas successfully replicated with one of it's replication partners.This is to avoid false or duplicate registration of records (or even duplicate creation of the application partitions). As such, with SP1 it's better to point your DCs to a replicationpartner as a primary DNS and to self as a secondary. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Donnerstag, 13. Juli 2006 17:02 To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Always point a DC with DNS installed toitself as the preferred DNS server...always? Hi Al I did want to throw in a personl experience I had with W2K3 that validates the "Point your DNS server
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
just found the description of the error and the pre-SP1 hotfix to the duplicate DNS app-partitions issue: http://support.microsoft.com/kb/836534/en-us From: Grillenmeier, Guido Sent: Freitag, 14. Juli 2006 20:34To: 'ActiveDir@mail.activedir.org'Subject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? there was no need to check on this issue again - with SP1 it doesn't happen ;-) I'm sure there were several pre-SP1 fixes targeted at this issue and were then integrated into SP1. but rgd. the startup behaviour of DNS in SP1, I'm rather sure that's unchanged at this point. Would be happy to be corrected. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Freitag, 14. Juli 2006 19:46To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Guido, have you checked this lately? I know there were several changes to that behavior in several revs IIRC. The problems you describe were better than a challenge, as I recall. they had a tenedancy to wreak havoc with integrated dns zones when a dc would come up and create a new zone and then replicate that. There were several fixes related though and that behavior might have changed several times. On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I'd have to do some more digging as to *why* the duplicateapp-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFMfeature to rollout the DCs. But prior to SP1 you couldn't add theapplication partitions to the dcpromo process (IFM in SP1 now offers anthe options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created theDomainDnsZones app-partiontion right after their first reboot, causingsome interesting challenges. Agree they should have contacted the DNmaster - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition.Anyways, to avoid similar issues, SP1 ensures that AD completes thereplication with one partner prior to allowing the DNS service to readit's records and to register anything. This is actually similar to the change that was done with either Win2000 SP2 or SP3 to avoid DCs toadvertise their GC status prior to finishing a replication cycle withanother GC or one DC of every domain in their site.The challenge here is that you get into a "race-condition" when using the DC itself as the primary DNS server - ofcourse this will still work,but you have to wait for many more timeouts during the reboot of the ADDC: for every DNS query prior to a successful replication, the DC will first try to query it's own DNS server and won't use the secondary untila DNS timeout...I've seen the boot-times of DCs go up to 10 and moreminutes.This can usually be fixed by setting the primary DNS server of the DC to another DNS server (naturally won't help, if both are bootedat once - consider this during your DR planning...)/Guido-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Paul WilliamsSent: Freitag, 14. Juli 2006 12:33To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itselfas the preferred DNS server...always?I can't see how you can get a duplicate NDNC as the creation of such objectsis targetted at the DN master. The DN master will check the existingcrossRefs and stop this happening, as we can't rely on the DS stoppingit asthe RDN is different for each NDNC (unless they've used "well-known" GUIDsfor the DNS NCs?).Although the behaviour you speak of is new to me, and another one ofthoseslight, interesting changes, so thanks for that.Can you elaborate on this new behaviour?What, exactly, happens and in whatorder?--Paul- Original Message -From: "Grillenmeier, Guido" [EMAIL PROTECTED]To: ActiveDir@mail.activedir.orgSent: Thursday, July 13, 2006 6:52 PMSubject: RE: [ActiveDir] Always point a DC with DNS installed to itselfasthe preferred DNS server...always? note that DNS startup behavious changes with SP1, which is another reason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until ithas successfully replicated with one of it's replication partners.This is to avoid false or duplicate registration of records (or even duplicate creation of the application partitions). As such, with SP1 it's better to point your DCs to a replicationpartner as a primary DNS and to self as a secondary. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] S
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
thanks for the additional information Steve - I would also be interested to hear the official recommendation rgd. DNS configuration on DCs in Win2003 SP1/SP2 and Longhorn. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve LinehanSent: Friday, July 14, 2006 8:41 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? I believe I covered most of this on a previous posting to ActiveDir but here are all of the details into what change was made and why: First of all the change that was made requires that an Initial Sync is completed before DNS will load the zones. This change was made after a customer reported a very nasty outage of all DNS records for one of their Domains. Needless to say with no DNS records many things break. So how and why did this happen. It turns out that many things have to come together but the end result is that we Conflict the MicrosoftDNS container, note not the application partition. This can occur do to a timing issue that was first seen when using an Install from Media (IFM) technique across a slow WAN link and of course you are not using the new feature in Windows Server 2003 SP1 that allows sourcing Application Partitions from media. Because Application Partitions have the lowest replication priority it was possible that the machine would register to host the DomainDNSZones application partition but never get a chance to replicate any information in do to it being pre-empted by higher priority Config and Domain partition replication. In that case if the timing was just right it was possible that the DNS server on this box would recreate the MicrosoftDNS container in order to store the root hints. This would of course replicate out and cause a CNF and since last writer wins you would end up with what looked like an empty MicrosoftDNS container, except for the root hints, which looked like corruption to all of the other DNS servers since they had records loaded from there at one point. To keep this from happening a requirement that the DC must perform an initial sync was put in place. This was the safest way to insure that we had replicated the necessary data in before trying to load zones and possibly conflict the MicrosoftDNS container. There were other places where this type of issue could pop up such as how we handle SOAs so the change was made. There is additional work being done in Windows Server Code Name Longhorn to help with this as well as other performance issues of loading large zones which caused slow DNS startup times. I have sent Email to the appropriate component owners so that they can revise if necessary our guidelines on how DNS should be configured for both Windows Server 2003 and the next version of the product. The only thing I would not recommend is removing the initial sync requirements by adding a registry value as this not only has affects on DNS but also the code that is used to insure that we do not have multiple machines believing that they are a particular FSMO owner. Here is the KB for the change that was introduced and rolled into SP1: http://support.microsoft.com/kb/836534/en-us . I have left out some of the hairy details as to exactly why the above happens as well as the customer who initially hit this, they know who they are. J Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Friday, July 14, 2006 12:46 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Guido, have you checked this lately? I know there were several changes to that behavior in several revs IIRC. The problems you describe were better than a challenge, as I recall. they had a tenedancy to wreak havoc with integrated dns zones when a dc would come up and create a new zone and then replicate that. There were several fixes related though and that behavior might have changed several times. On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I'd have to do some more digging as to *why* the duplicateapp-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFMfeature to rollout the DCs. But prior to SP1 you couldn't add theapplication partitions to the dcpromo process (IFM in SP1 now offers anthe options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created theDomainDnsZones app-partiontion right after their first reboot, causingsome interesting challenges. Agree they should have contacted the DNmaster - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition.Anyways, to avoid similar issues, SP1 ensures that AD completes thereplication with one partner prior
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
note that DNS startup behavious changes with SP1, which is another reason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until it has successfully replicated with one of it's replication partners. This is to avoid false or duplicate registration of records (or even duplicate creation of the application partitions). As such, with SP1 it's better to point your DCs to a replication partner as a primary DNS and to self as a secondary. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Donnerstag, 13. Juli 2006 17:02 To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Hi Al I did want to throw in a personl experience I had with W2K3 that validates the Point your DNS server to a replication partner theory. I did see in one environment where every DC had DNS and the msdcs partition was a forest partition. An unfortunate DNS scavenge was done deleting some of the GUID records in the MSCDCS partition. Replication started to fail shortly after that and the missing GUIDs were discovered. The netlogon service was restarted to make the DCs re-register but of course they re-registered the GUID on themselves. They could find themselves but not their replication partners. The replication partners could find them but not themeselves. When the DCs were set to point to a hub replication partner for primary and themselves as secondary the problem went away - the netlogon service was restarted, the GUIDs registered on the central DNS server, the spokes did the lookup for replication parnters on the hub site DC and eventually things started working again. This was pre - SP1 so this may not be a problem anymore, but after that experience I have seen value in doing the DNS configuration so that the DCs all point to the hub first and themselves second. I have not seen any problems for the DC itself when the WAN link dropped for a length of time and the primary DNS server was not reachable. Of course, if there are never any changes to DC IPs or names and the MSDCS is never scavenged (or the interval is long enough not to recreate the above problem) then the above argument is moot. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service 202-230-2983 [EMAIL PROTECTED] Al Mulnick [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent by: cc: (bcc: James Day/Contractor/NPS) [EMAIL PROTECTED]Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the tivedir.org preferred DNS server...always? 07/12/2006 09:58 PM AST Please respond to ActiveDir You don't work at the post office do you? ;) There are many many many ways to properly configure DNS. One thing that helps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard. Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND. Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client* to another DNS server that hosts the zones. You're also talking about making dc1 a client of dc2 and vice versa. That's silly, but I'll get to that. If you have your dns hosted on a third party system such as BIND, you'll have one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization) and your DC would be a client of that system. If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configure your DC's to be clients of the BIND or Microsoft DNS servers. If you have the the DNS AD-Integrated, then after initial replication you should have the client configured to use itself as the DNS server. That'd be the best practice. Before 2003 you could have an
RE: [ActiveDir] AD Sites Rename
not a problem for AD or most apps that use it - potentially an issue with scripts that use hardcoded names. Clients will fail to find their DC that they've last used and will need to do a generic DNS query prior to finding the renamed site again. Usually no big deal. If your DFS root servers are Win2000, you'd need to refresh the site data (using dfsutil I believe) - if they're Win2003, they look up site information dynamically and don't care abouta rename. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James CarterSent: Donnerstag, 13. Juli 2006 12:32To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] AD Sites Rename Hi, I need to rename some of my AD Sites, is this likely to cause any issues I am unaware off? I use DFS if thats any help. Windows 2003 Single Domain/Forest FFL. thanks James Do you Yahoo!?Next-gen email? Have it all with the all-new Yahoo! Mail Beta.
RE: [ActiveDir] Object Auditing
I'd have to check out myself if an OU move is possible to audit with the built-in auditing events - I'm pretty sure though it is possbile with AD specific auditing software such as NetPro's ChangeAuditor AD and Quest's Intrust for AD. you may also want to disable drag drop in your forest, simply by configuring the following (works for Win2003 SP1 - a pre-SP1 fix should be available as well): use ADSIEDIT, LDPor equivalent tool locate "flags" attribute of DisplaySpecifiers container in config. NC set bit 0 to 1 drag and drop now disabled /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clay, Justin (ITS)Sent: Donnerstag, 13. Juli 2006 20:25To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Object Auditing Is it possible to audit the creation/deletion and more importantly, the movement of OUs? One of our admins dragged and dropped an entire OU into another OU that had a desktop lockdown GPO linked to it, thereby locking down the PCs of a bunch of important people, and making them very upset. I have Account Management and Object Access auditing on, but I dont see anything on any of our DCs that show anything about the OU or any of its objects moving. Is there something else I need to enable to audit these types of events? Is it even possible? Thanks, Justin ClayITS Enterprise Services Metropolitan Government of Nashville and Davidson County Howard School Building Phone: (615) 880-2573 ITS ENTERPRISE SERVICES EMAIL NOTICEThe information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
RE: [ActiveDir] Windows 2003 sp1 DNS problem
I wasn't aware that this was a change in SP1, but it sounds as if StrictNameChecking is enabled on your server after you've added SP1 (http://support.microsoft.com/default.aspx?scid=kb;en-us;281308) You ca disable it in general by configuring the DisableStrictNameChecking reg-key as the KB above explains. However, this would allow to access the server via _any_ name. I typically suggest to use the reg-keys to limit additional names to those you really want: DNS: HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\AlternateComputerNames (Multi-SZ) NetBios: HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\Parameters\OptionalNames (Multi-SZ) This can also be done via the Win2003 version of NETDOM: NETDOM COMPUTERNAME current NetBIOS or DNS name /add:additional FQDN name /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Donnerstag, 29. Juni 2006 21:38To: ActiveDir@mail.activedir.orgCc: [EMAIL PROTECTED]Subject: [ActiveDir] Windows 2003 sp1 DNS problem Hallow all. I need help in a problem I have after installing Service Pack 1 This is the case: I have a windows 2003 Server (I Will call it SERVER01), without service pack 1 I created a dns name like this aplicacao.mycompany.com Before installing SP1, when I called locally \\aplicacao.mycompany.com It opened shared folders perfectly Now , after SP1, if I call \\aplicacao.mycompany.com It asks for a user and password. I don´t know witch password or user is that... If I call \\SERVER01.mycompany.com, it works. What was changed after installing SP1? how can I correct that? Adrião
RE: [ActiveDir] NTDS.DIT Size
1.7GB for 250.000 users is pretty small already - I guess you don't use Exchange for messaging or use extremely few attributes of your objects in AD. With the steps outlined by Ulf you should get a fair idea on how much whitespace you currently have, however, you shouldn't expect to have much if your AD is growing at a fairly constant rate. The database grows fairly linear and whitespace is being used automatically be new data. As you're talking about moving to 64-bit, I guess you're already using Win2003. On 32-bit Windows 2003 DCs without /3GB switch, the LSASS process can consume (cache) up to about 1.5GB, with /3GB it's around 2.6GB. /3GB is supported on both Standard and Enterprise Edition with respect to DCs. So theoretically you're well in the limits of the 32-bit OS, as long as you have at least 4GB in your DCs and are using the /3GB switch. However, the /3GB switch reduces the vitual memory for the kernel down to 1GB, with can be a limiting factor in other situations - usually not on a DC (if it's not also hosting many other services). But the 64-bit DCs won't cost you one penny extra: almost all server HW for the past 12 months has been x64 capable and the 64-bit Win2003 version has the same licensing costs as the 32-bit version. So you might as well go for it and have even more room for growth. Mind you, with your currentDIT sizeyou should not expect much performance difference for your AD (unless you're replacing old server HW with new HW at the same time...). /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-WeidnerSent: Donnerstag, 29. Juni 2006 23:47To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] NTDS.DIT Size Hello Joshua, Id look at the whitespace to determine when to offline defrag a DC. You can enable the associated event which will tell you the amount of whitespace by setting the registry key HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\6 Garbage Collection to 1 instead of 0 (which is the default). Regkey might be likely just typed it from hard. This will give you an event every time when garbage collection runs (every 12 hrs) and tell you the amount of whitespace in the DB. Whatever needs to be loaded should perform better when smaller. Ive heard that a DC on x64 will perform better than on 32-bit, since its very likely you already have some of the newer servers with x64 Id just give it a try for one DC yourself. Gruesse - Sincerely, Ulf B. Simon-Weidner Profile Publications:http://mvp.support.microsoft.com/profile=""> Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua CoffmanSent: Thursday, June 29, 2006 10:59 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] NTDS.DIT Size Our AD (NTDS.dit) is at 1.7GB (approx. 250,000 users).Should an offline defrag be performed at a regular interval?Some articles I read only say it is only worthwhile if you are running low on space.We have plenty of drive space and RAM.At what point should the AD be moved to 64 bit?Thanks,Josh
RE: [ActiveDir] Deny permissions in AD
... because there could be other explicit rights on the objects further below in the tree that do allow to view all kind of objects and properties. For example: Authenticated Users. Unless you've removed these rights, it is likely that if you search for objects in you the OU (if it has sub-OUs), you'll still be able to find many and view their properties... /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitri GavrilovSent: Montag, 26. Juni 2006 21:49To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Deny permissions in AD The cleanest way is not to deny permissions but to revoke permissions. In other words, you should remove ACEs that are granting access that you dont need. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua CoffmanSent: Monday, June 26, 2006 11:22 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Deny permissions in AD I think you are correct.I started lookinginto this immediately after posting.Looks like domain admins, Self, and account operators have hard-coded rights to the object.This would be applied before the inherited deny ACE.Thanks!JoshJoshuaM.Coffman[EMAIL PROTECTED]Cell:(970)402-3457 Subject: RE: [ActiveDir] Deny permissions in ADDate: Mon, 26 Jun 2006 13:50:13 -0400From: [EMAIL PROTECTED]To: ActiveDir@mail.activedir.org Probably order of inheritance 1. Noninherited Deny entries. 2. Noninherited Allow entries. 3. Inherited Deny entries. 4. Inherited Allow entries. :m:dsm:cci:mvp| marcusoh.blogspot.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua CoffmanSent: Monday, June 26, 2006 1:44 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Deny permissions in AD I have an Active Directory 2003 domain that is used only as an LDAP User store for a 3rd party Identity Management Application.There are no workstations or servers in the domain, other than the DCs themselves.We are trying to lock down the domain, so that an ordinary user cannot read other user's attributes. For some specialattributes, we have implemented the 2K3 SP1 "Confidential Attribute" function, and it is working well.However, over the weekend, another administrator decided to try something that has me a little perplexed.Here is what the Admin did:Put a DENY ACEfor the "Domain Users" groupfor"Read All Properties" (in advanced security settings) on an OU containing a lot of users.Now, your average user account cannot read attributes, which is good. Domain Admins and Administrators can read the attributesof users in the OU,which is also good.However, I am wondering, whydoes thiswork this way? Shouldn't the DENYACE override all other permissions, including those inherited for domain Admins, which I believe is a member of the domain users group by default. Also, an additional group was created which allows read/write access to a singleuser attribute in the same OU. A non-administrative account, when added to this group,can read andwrite to the attribute, even though there is a deny on readall properties.Can anyone tell me why this is working this way? It is contrary towhat I thought Iknew about Deny ACEs.Thanks,Josh
RE: [ActiveDir] Servers or Workstations
servers first? workstations first? first what? I assume you're talking about migrating your servers and workstations from an NT4 domain to an AD domain - correct? If so, the order strongly depends on various aspects, such as the status of your user and group migration and how you handle permissions on your servers. There's too much detail here to know, which doesn't make sense to add without knowing more about your environment. But more often than not it is more advisable to 1. migrate your users accounts and groups to AD 2. take care of the user profiles on the workstations and ensure that the users are actually using the AD account (often combined with the computer migration) 3. migrate the servers and any other workstations to AD Usually the order of workstation or servers is not important - this changes if you have a lot of trusts in your environment and need to ensure availability of specific trusted resources from other domains that have not been migrated yet. Suddenly the order can become important again. So maybe you want to enlighten us a little about your environment, such as trusts between your domains, usage of SidHistory for account/group migration, usage of local profiles/roaming profiles on workstations, terminal servers, tools you're using for the migration etc. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Strongosky Sent: Mittwoch, 21. Juni 2006 00:22 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Servers or Workstations Thanks Rob, thought so... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Rutherford Sent: Tuesday, June 20, 2006 3:13 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Servers or Workstations Hi John, I would 'generally' opt for servers first as you can then take advantage of the 2K, 2K3 goodies, i.e. AD straight away when you migrate the workstations. 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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Strongosky Sent: 20 June 2006 18:37 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Servers or Workstations Hey all, I thought I had our Ad Migration plan as we were going to do workstations first but I'm having second thoughts. I think we should do servers first then workstation's. Could I have your thoughts on this. Thanks john List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
RE: Re: [ActiveDir] Errors During Authoritative Restore
glad Brett picked up on analysing the different errors you were getting - I've not seen these before. curious to hear what type of issue you aretesting to recover from? From what you write, I gather you are testing to restore your production domain to another (hopefully physically separated) test-system. I.e. you are testing a full recovery of your ADdomain or forest- is this correct? If so, authorititative restore of the AD DB is not the right approach anyways. The restore database option gives the false impression of doing a full recovery of AD - it bears more risks than value and likely this is why it was removed from Longhorn. In a distributed multi-master database such as AD, auth. restoring the partition of one DC will never completely overwrite the same partition of the other DCs: although you might be lucky and think you have fully recovered, any additional objects or new attributes added to existing objects in the respective AD partition after you performed the backup will replicate back to the restored DC. The correct way to fully restore AD is to restore only a single instance of the DB (i.e. a single DC) and re-build / re-promote all the other DCs. Instead of performing an auth. restore of the DB, you'd just restore it non-authoritatively anddo a metadata cleanup of all the otherDCs on the restored DC to ensure it is the only one representing your domain (you would mark SysVol as primary during the restore process). There are a few more steps to perform to ensure that the recovered DC doesn't replicate any data from other existing DCs in your environment - all of these are described in the (fairly old) AD Forest Recovery Whitepaper which pretty much also applies for full recovery of a single domain: http://www.microsoft.com/downloads/details.aspx?displaylang=enFamilyID=3EDA5A79-C99B-4DF9-823C-933FEBA08CFE It's a little more complex in a multi-domain environment as you also have to take care of the partitions of your domain on GCs in other domains - if you're goal is to also fully restore the config partition, you're talking about a full forest restore anyways (which would roughtly use the same approach - restoring a single DC of every domain - then re-promoting all other DCs). Although LH backup and recovery procedures are not fully finalized yet, for full AD recovery the process would still roughly be the same asdescribed above(mind you there are big changes to the built-in backup-tool - and recovery of a DC to different HW should now also be a valid option). The main change with LH that will strongly influence time and risk for a domain/forest level restore is the fact that you will not have as many writeable DCs in your environment. Even if you are strongly distributed geographically, the goal will be to only host writeable DCs in your datacenters and make all the other DCs in your environment read-only. As the name implies, the Read-Only DCs (RODC) do not allow any originating writes on them and will never replicate anything back to a writeable DC - this way there is less work involved to ensure a consistent status of AD during the recovery. Not saying you won't also have to re-promote the RODCs, but you certainly have less writable DCs to worry about and can possible leave the RODCs running during the recovery process (we'll have to see about this).I have good hopes that this will increase the overall recovery-speed of AD inlarge distributed deployments. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua CoffmanSent: Dienstag, 20. Juni 2006 21:33To: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] Errors During Authoritative Restore Thanks Brett,I appreciate your assistance on this.Yes, there are tons of schema mods.In the domain throwing the majority of the errors, these mods were performed using an LDIF file, during the installation of a 3rd partyIdentity Management Application.I do not know if therehave beenLDAP naming attributes added or not. If you can send a query to verify, I would be happy to run it.I knew that Restore Database is the "last resort" method, but that is what we wanted to test. We do have multiple DCs replicating across multiple geographic sites, so this scenario is unlikely, unless there were some sort of catastrophic corruption that took place.In the future, if "restore database" is unavailable, what will be used in its place if you need to do a bare metal authoritative restore of the entire AD?It will take a while to run the tools you requested against the AD, because it is a production system. I cannot run them directlyin the PROD environment, so I would have to pull a mirrored drive from the prod DC, and pop it into an offline server. This could take a while for the required approvals.Thanks again for your help!Josh Date: Tue, 20 Jun 2006 10:09:58 -0700 From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Errors During
RE: [ActiveDir] can I exclude a particular user account from authenticated users?
same question here: there's nothing you can really do to control the addition of specific SIDs to the security token of any account during logon - the Authenticated Users SID is one of those (besides many other well-known-security-principals controlled by the system). but if you tell us what you're trying to accomplish, we may be able to help you reach your goal in other ways. For example, by not using Authenticated Users to secure any data that you want to restrict access to in any way... :-) /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Dienstag, 20. Juni 2006 14:43To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] can I exclude a particular user account from "authenticated users"? I'm just curious why you would want to remove an authenticated user from the authenticated users group? What's the goal? On 6/20/06, joe [EMAIL PROTECTED] wrote: Disable the account's ability to authenticate. Makes the account rather worthless but it is the only thing I can think of that would accomplish the stated goal. Programmatically you might be able to modify the token at the local machine levelsuch that the auth users SID isn't enabled, but that would take some rather involved work I expect. See http://msdn.microsoft.com/library/default.asp?url="" . It isn't anything I have tried, just a theory based on some reading I have done in the API docs. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Thommes, Michael M. Sent: Monday, June 19, 2006 10:31 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] can I exclude a particular user account from "authenticated users"? This may sound like an off the wall question, but I would like to exclude a particular user account from the built-in security principal "Authenticated Users ". Is there any way to do this? TIA! Mike Thommes
RE: [ActiveDir] How to block particular Subjects
not until you send us your resume ;-) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ajay KumarSent: Mittwoch, 21. Juni 2006 08:38To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] How to block particular Subjects Hi all, I just wanna to know that, Is that possible to block particulars subjects Ex: ( Resume ). when user send any mail related to same subject to other domain ( Internet ). We are using exchange server 2003 and atleast 500 users. Pls give me any suggestion / Software through I can block particular subjects Regards, Sam
RE: Re: [ActiveDir] Errors During Authoritative Restore
"Isn't this what you want?" yes and no - it really depends on what you're trying to achieve. Josh was trying to do a complete AD DR - not a recovery of a failed DC. For a failed DC you'd want it to replicate the other changes after a successful (non-auth) restore. But if you want to complete "turn back the clock" and restore AD to a previous state (such as in a full domain/forest DR scenario), you certainly do not want to replicate any newer changes from other DCs... /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky HabeebSent: Mittwoch, 21. Juni 2006 22:38To: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] Errors During Authoritative Restore Guido, I am confused. You wrote, "any additional objects or new attributes added to existing objects in the respective AD partition after you performed the backup will replicate back to the restored DC." Isn't this what you want? I am assuming that the goal was for him to recover one or more DCs that went down. But if the network stayed up and he is truly in a multi-master environment, then why would you not want changes made after the disaster (password changes, new users added, etc) to replicate back? Don't the other DCs now have the correct system state on them and don't you now want the recovered DC to mirror those? RH __ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Grillenmeier, GuidoSent: Wednesday, June 21, 2006 3:48 AMTo: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] Errors During Authoritative Restore glad Brett picked up on analysing the different errors you were getting - I've not seen these before. curious to hear what type of issue you aretesting to recover from? From what you write, I gather you are testing to restore your production domain to another (hopefully physically separated) test-system. I.e. you are testing a full recovery of your ADdomain or forest- is this correct? If so, authorititative restore of the AD DB is not the right approach anyways. The restore database option gives the false impression of doing a full recovery of AD - it bears more risks than value and likely this is why it was removed from Longhorn. In a distributed multi-master database such as AD, auth. restoring the partition of one DC will never completely overwrite the same partition of the other DCs: although you might be lucky and think you have fully recovered, any additional objects or new attributes added to existing objects in the respective AD partition after you performed the backup will replicate back to the restored DC. The correct way to fully restore AD is to restore only a single instance of the DB (i.e. a single DC) and re-build / re-promote all the other DCs. Instead of performing an auth. restore of the DB, you'd just restore it non-authoritatively anddo a metadata cleanup of all the otherDCs on the restored DC to ensure it is the only one representing your domain (you would mark SysVol as primary during the restore process). There are a few more steps to perform to ensure that the recovered DC doesn't replicate any data from other existing DCs in your environment - all of these are described in the (fairly old) AD Forest Recovery Whitepaper which pretty much also applies for full recovery of a single domain: http://www.microsoft.com/downloads/details.aspx?displaylang=enFamilyID=3EDA5A79-C99B-4DF9-823C-933FEBA08CFE It's a little more complex in a multi-domain environment as you also have to take care of the partitions of your domain on GCs in other domains - if you're goal is to also fully restore the config partition, you're talking about a full forest restore anyways (which would roughtly use the same approach - restoring a single DC of every domain - then re-promoting all other DCs). Although LH backup and recovery procedures are not fully finalized yet, for full AD recovery the process would still roughly be the same asdescribed above(mind you there are big changes to the built-in backup-tool - and recovery of a DC to different HW should now also be a valid option). The main change with LH that will strongly influence time and risk for a domain/forest level restore is the fact that you will not have as many writeable DCs in your environment. Even if you are strongly distributed geographically, the goal will be to only host writeable DCs in your datacenters and make all the other DCs in your environment read-only. As the name implies, the Read-Only DCs (RODC) do not allow any originating writes on them and will never replicate anything back to a writeable DC - this way there is less work involved to ensure a consistent status of AD during the recovery. Not saying you won't also have to re-promote the RODCs, but you
RE: [ActiveDir] Servers or Workstations
yes, this approach would work fine. Important is to finish step 1+2 before you do 3+4. As your AD domain has trusts to both source domains and it doesn't look like you're leveraging windows file-servers, you could also do step 5 early on (would be different if you are leveraging a lot of Windows File Servers - SIDhistory has some nice surprises here). BTW, step 3+4 can be done at once (but I also preferr to keep them apart) /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Strongosky Sent: Mittwoch, 21. Juni 2006 17:15 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Servers or Workstations Guido, thanks, for the feed backhere is the info about our domain. 2 nt4 domains, 1 an account and 1 a resource with a 2 way trust between them. No roaming profiles. Servers have shares on them for web development. Novell is our file server's. We do direct ip printing. Have 1 Citrix Server. Have migrated groups first then users with sid history using ADMT v3.0 and now am starting on workstation's/servers but I used my self as a test dummy and screwed up my workstation (this worked in our lab) by not having access to an Helpdesk application that uses a share and logging on to the AD domain before I had migrated my profile. So if I'm doing this correctly the scenario for this AD migration using ADMT v 3.0 should be: 1. Migrate Groups from both Domains with sid history. 2. Migrate Users with Sid history and fix group membership. 3. Migrate User Profiles using the Security Translation Wizard selecting to do only the profile/User rights and adding security references selecting the source domain workstations. 4. Migrate the workstation using the Computer Migration Wizard but leave the Users Profiles and User rights unchecked 5. Migrate Servers using the Security Translation Wizard and then the Computer Migration Wizard. john -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, June 20, 2006 11:48 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Servers or Workstations servers first? workstations first? first what? I assume you're talking about migrating your servers and workstations from an NT4 domain to an AD domain - correct? If so, the order strongly depends on various aspects, such as the status of your user and group migration and how you handle permissions on your servers. There's too much detail here to know, which doesn't make sense to add without knowing more about your environment. But more often than not it is more advisable to 1. migrate your users accounts and groups to AD 2. take care of the user profiles on the workstations and ensure that the users are actually using the AD account (often combined with the computer migration) 3. migrate the servers and any other workstations to AD Usually the order of workstation or servers is not important - this changes if you have a lot of trusts in your environment and need to ensure availability of specific trusted resources from other domains that have not been migrated yet. Suddenly the order can become important again. So maybe you want to enlighten us a little about your environment, such as trusts between your domains, usage of SidHistory for account/group migration, usage of local profiles/roaming profiles on workstations, terminal servers, tools you're using for the migration etc. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Strongosky Sent: Mittwoch, 21. Juni 2006 00:22 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Servers or Workstations Thanks Rob, thought so... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Rutherford Sent: Tuesday, June 20, 2006 3:13 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Servers or Workstations Hi John, I would 'generally' opt for servers first as you can then take advantage of the 2K, 2K3 goodies, i.e. AD straight away when you migrate the workstations. 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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Strongosky Sent: 20 June 2006 18:37 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Servers or Workstations Hey all, I thought I had our Ad Migration plan as we were going to do workstations first but I'm having second thoughts. I think we should do servers first then workstation's. Could I have your thoughts on this. Thanks john 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: Re: [ActiveDir] Errors During Authoritative Restore
yep, that's it - no need to perform the auth restore of AD in your scenario From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua CoffmanSent: Mittwoch, 21. Juni 2006 17:56To: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] Errors During Authoritative Restore Thanks again for your help. I appreciate your feedback and expertise on the subject.Youare correct, this is a test of a bare-metal restore of the entire domain, where I bring in tapes from offsite and restore a single DC to a completely disconnected machine (on identical hardware). In this worst-case scenario, the plan was to restore asingle DC, perform metadata cleanup, and rebuild and dcpromo new replicas. I was under the impression that in order to restore the entire database from scratch, you had to mark the SYSVOL as primary, and perform an authoritative restore: restore database. Are you saying you just restore from tape, mark SYSVOL as primary, skip the auth restore commands in NTDSUTIL, and just perform the metadata cleanup functions, clean DNS, etc. and you are good to go? If this is correct, it would be a much cleaner/faster process, because we wouldn't have to be updating USNs on a half-million objects. It makes sense that it would not have to be authoritative, if all replica DC's were going to be new, but I(probably mistakenly)thought that the authoritative restore was a required step.Thanks!Josh Subject: RE: Re: [ActiveDir] Errors During Authoritative RestoreDate: Wed, 21 Jun 2006 08:48:25 +0100From: [EMAIL PROTECTED]To: ActiveDir@mail.activedir.org glad Brett picked up on analysing the different errors you were getting - I've not seen these before. curious to hear what type of issue you aretesting to recover from? From what you write, I gather you are testing to restore your production domain to another (hopefully physically separated) test-system. I.e. you are testing a full recovery of your ADdomain or forest- is this correct? If so, authorititative restore of the AD DB is not the right approach anyways. The restore database option gives the false impression of doing a full recovery of AD - it bears more risks than value and likely this is why it was removed from Longhorn. In a distributed multi-master database such as AD, auth. restoring the partition of one DC will never completely overwrite the same partition of the other DCs: although you might be lucky and think you have fully recovered, any additional objects or new attributes added to existing objects in the respective AD partition after you performed the backup will replicate back to the restored DC. The correct way to fully restore AD is to restore only a single instance of the DB (i.e. a single DC) and re-build / re-promote all the other DCs. Instead of performing an auth. restore of the DB, you'd just restore it non-authoritatively anddo a metadata cleanup of all the otherDCs on the restored DC to ensure it is the only one representing your domain (you would mark SysVol as primary during the restore process). There are a few more steps to perform to ensure that the recovered DC doesn't replicate any data from other existing DCs in your environment - all of these are described in the (fairly old) AD Forest Recovery Whitepaper which pretty much also applies for full recovery of a single domain: http://www.microsoft.com/downloads/details.aspx?displaylang=enFamilyID=3EDA5A79-C99B-4DF9-823C-933FEBA08CFE It's a little more complex in a multi-domain environment as you also have to take care of the partitions of your domain on GCs in other domains - if you're goal is to also fully restore the config partition, you're talking about a full forest restore anyways (which would roughtly use the same approach - restoring a single DC of every domain - then re-promoting all other DCs). Although LH backup and recovery procedures are not fully finalized yet, for full AD recovery the process would still roughly be the same asdescribed above(mind you there are big changes to the built-in backup-tool - and recovery of a DC to different HW should now also be a valid option). The main change with LH that will strongly influence time and risk for a domain/forest level restore is the fact that you will not have as many writeable DCs in your environment. Even if you are strongly distributed geographically, the goal will be to only host writeable DCs in your datacenters and make all the other DCs in your environment read-only. As the name implies, the Read-Only DCs (RODC) do not allow any originating writes on them and will never replicate anything back to a writeable DC - this way there is less work involved to ensure a consistent status of AD during the recovery. Not saying you won't also have to re-promote the RODCs, but you certainly have less writable DCs to worry
RE: [ActiveDir] Cross forest issue
Mike, as others have mentioned, users and groups from externally trusted domains can only be added to domain local groups (DLG) in another forest. This is by design for any type of trust that you establish. If all you're trying to do is to manage the member servers in your DMZ with the same admin accounts that you have in your production forest, you could still leveragea GPO in your DMZ forest/domain that either adds a DLG to the adminsitrators group of all your DMZ servers using the restrictive groups feature. If you combine this approach with enabling Selective Authentication for the trust between the two forests and use this feature to restrict authentication to the servers to members of the same group, you'll have a reasonable integration of the two forests to allow managment of the DMZ servers using your production admin accounts. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guest, MikeSent: Donnerstag, 15. Juni 2006 19:24To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Cross forest issue Hi, New member here, with an issue L We have implemented 2 forests with a cross forest trust such that forest B trusts forest A one-way. The intention is that all admins in forest A will be able to manage both forests, and that accounts in forest B cannot be authenticated in forest A Whilst I can add the admins from forest A into a domain local group in forest B, allowing me to grant administrators rights, I cannot add any security principal from forest A to a universal (or global) group in forest B. This precludes me from granting domain, enterprise or schema admin rights to the forest A administrators and thus defeats the objective of having the admins in a single forest. (FYI, creating a DL, adding a remote user, then trying to change that group to a universal group gives the message Foreign security principals cannot be members of universal groups) Forest B is in a DMZ, and is solely being used to give the benefits of centralised management to the servers in the DMZ. Consequently, we want to avoid having many user accounts in that forest. Company policy states that every admin must log on using their own account Hope you can help. __Mike Guest| Capgemini | Sale Server Support | Outsourcing UKOffice: + 44 (0)870 366 1814 | 700 1814| [EMAIL PROTECTED]77-79 Cross Street, Sale, Cheshire. M33 7HG Join the Collaborative Business Experience__ This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
RE: [ActiveDir] Profile migration to new domain
just in case you've not yet proceeded with any of your actions: a trust is not a requirement to migrate your users and do the profile updates on the clients or in fact to migrate objects from one domain to another. You can work just fine with passthrough-authentication instead (i.e. using an admin user + password from one domain, that is the same as an admin user + password in the other domain). You are however limited in what you can migrate = e.g. you won't be able to migrate the user passwords and you won't be able to use SIDhistory.Both should be uncritical if you only have to migrate 40 users... ADMT basically performs the steps that Susan described in the "User Profile Registry" part. There is however one little step missing in that list of steps, which is to grant the new user account full control over the old profile path directory on the respective client - this is also being taken care of automatically by ADMT. Your benefit: you can also migrate groups and group memberships (or merge the users into existing groups in the target domain), if this is required in your case. Don't know any details of your environment, so maybe you don't want to take over the groups and memberships of the users you are migrating accross... /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Condra, Jerry W Mr HPSent: Freitag, 2. Juni 2006 17:04To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Profile migration to new domain Thanks to everyone for the input. Definitely helpful. Looks like the lack of a domain trust is going to prevent most methods. Well have to resort to a manual process along the lines of Susans steps unless they can be convinced to just come over fresh. And yes, the kool-aid is plentiful. ;-) Many thanks Jerry From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Friday, June 02, 2006 9:10 AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Profile migration to new domain Silly, just go back to the OEM version. It's already paid for, supported, etc. If not, let me know and I'll forward my shipping address off-line. G As for the Dell support, I've found that using their support web controls often helps. Unless there was a mod on the machine, it's likely that they have the driver out there. You *could* always go to the nic manufacturer and get a driver there as well. I don't think that Mr HP has that issue though. I'm pretty sure he has a large pool with which to get licenses and likely has a support contract that he can utilize for assistance getting tools, drivers, advice, developer interaction, kool-aid, etc. Just a guess though. :) Al On 6/1/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote: Well I nuked and paved a formerly Dell OEM now a retail OS.. and nowcan't get the NIC on the motherboard to find nic driversanyone for a black decorative doorstop until I find the driver it wants or throw aintel card in there?Small firms wea. don't have the proper license to nuke/pave/reimageb. may not have the proper media to restore (you get the lovely OEM view of 'restoration media')c. We're already running the kitchen sink service as it is and now youwant us to RIS on that box as well?Geeze guys(it can do it but werecommend you turn it on when you need it and turn it off otherwise Exchange isn't a real happy camper sharing mem space)Al Mulnick wrote: Sorry ma'am.I should have completed my sentence and said, "..unless Susan can post the step by step directions." Silly me for not proof reading first. I'd still opt for nuke and pave in that environment. Allows you to have a known state, and last I checked that's kind of important to the type of customer he has. Now he has more options. USMT would have been a thought except that there is no trust and no reason to move the sid that I can think of.Same reason that moveuser wouldn't really matter to me.I'd prefer the control of creating the users as new users.In effect, they are new users (secprin's) anyway - treat 'em that way. Susan offers a way to get the settings and magical icons though. That's a nice touch an option if so taken. On 6/1/06, *Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Rip out a profile?Nuke and pave? Bite your tongue sir... we want that icon to be exactly right THERE on the desktop. file/transfer wiz in XP (but don't get docs..just do settings) Download details: Windows Server 2003 Resource Kit Tools: http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffddisplaylang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffddisplaylang=en Moveuser.exe How to migrate user accounts: http://www.microsoft.com/technet/windowsvista/library/6730111b-b111-4a64-8f00-af87a63fd157.mspx Moveuser - Move between
