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,
[ActiveDir] R2 In-Place Upgrade bug ?
Morning to all -I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence:The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g. telnet server ip 389 from the mail server works. \\serverip or servername brings up the shared printers and folders perfectly. outbound traffic and icmp works fine, inbound icmp returns a time out.scenario:Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2.connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/modelinstalled new nic drivers and prosetupgraded to R2.rebooted and noticed a ton of errors with services hanging upon boot.checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled.i disabled IPSEC and entered dword value for ProhibitIpSec - nothingi then enabled ICF configured exceptions - explicitly allowing ICMP, and still nothing.reset the TCP/ip stack and winsock using netsh, nothing servers has two nics, one of which is disabled. changed binding order so active is on top -- nothingreinstalled the binaries of windows 2003 sp1 and upgraded to r2 again -- nothing.i'm at a lost of ideas and sure could use to vast resources the contributors of this group may have or know of. Thanks,-- HBooGz:\
Re: [ActiveDir] R2 In-Place Upgrade bug ?
So it works while its W2k3-SP1 but then breaks once upgraded to R2?What did you mean by incoming connections? Did you just mean ICMP? or actual connections like to certain services? Are the other DCs allowing incoming ICMP echo requests and allowing replies out? Are they also W2K3 -SP1? I assume there is no other firewall software from thirdparty AV or anything else installed.Just an idea. Is it worth checking the rsop.msc for Computer Configuration/Administrative Templates/Network/Network Connections/WIndows Firewall/Domain Profile and Standard Profile /Allow ICMP exceptions? Sounds to me like a security configuration wizard was run on it.I'd wait for someone more knowledgeable to say something if I were you ;-) Still, it doesnt hurt to check.CheersM@ On 7/29/06, HBooGz [EMAIL PROTECTED] wrote: Morning to all -I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence:The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g. telnet server ip 389 from the mail server works. \\serverip or servername brings up the shared printers and folders perfectly. outbound traffic and icmp works fine, inbound icmp returns a time out.scenario:Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2.connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/modelinstalled new nic drivers and prosetupgraded to R2.rebooted and noticed a ton of errors with services hanging upon boot.checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled.i disabled IPSEC and entered dword value for ProhibitIpSec - nothingi then enabled ICF configured exceptions - explicitly allowing ICMP, and still nothing.reset the TCP/ip stack and winsock using netsh, nothing servers has two nics, one of which is disabled. changed binding order so active is on top -- nothingreinstalled the binaries of windows 2003 sp1 and upgraded to r2 again -- nothing.i'm at a lost of ideas and sure could use to vast resources the contributors of this group may have or know of. Thanks,-- HBooGz:\
RE: [ActiveDir] R2 In-Place Upgrade bug ?
Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . Kurt Falde From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of HBooGz Sent: Saturday, July 29, 2006 5:39 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] R2 In-Place Upgrade bug ? Morning to all - I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence: The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g. telnet server ip 389 from the mail server works. \\serverip or servername brings up the shared printers and folders perfectly. outbound traffic and icmp works fine, inbound icmp returns a time out. scenario: Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2. connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/model installed new nic drivers and proset upgraded to R2. rebooted and noticed a ton of errors with services hanging upon boot. checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled. i disabled IPSEC and entered dword value for ProhibitIpSec - nothing i then enabled ICF configured exceptions - explicitly allowing ICMP, and still nothing. reset the TCP/ip stack and winsock using netsh, nothing servers has two nics, one of which is disabled. changed binding order so active is on top -- nothing reinstalled the binaries of windows 2003 sp1 and upgraded to r2 again -- nothing. i'm at a lost of ideas and sure could use to vast resources the contributors of this group may have or know of. Thanks, -- HBooGz:\
Re: [ActiveDir] R2 In-Place Upgrade bug ?
I applied no post sp-1 fixes, but i would imagine it's worth a try.do you guys want to hear something even more mind-boggling ?i can ping the server from workstations outside the main office!!!i've remotely connected to workstations at our IPSEC vpns to test login times and email access,a nd pinged the problematic server just fine!!! arghhhMatheesha:Incoming connections i mean services that somehow are not defined to the server. I run a repadmin /replsum from another dc and it shows no errors. i run a dcdiag /s:problemserver with no problem. so it means that directory service traffic is allowed, but when i try to Dameware ( tcp port 6129) to the machine it times out, when i try to the ping the box i get nothing from the main office! i checked the IPSEC domain and Standard profile and made sure no IPSEC polocies were applied. if it's the SCW -- how do i look at it ?could it someway be my checkpoint firewall at the local site ? how in the world can it accept icmp from other workstations ( win2k pro) at my remote vpn sites ? On 7/29/06, Kurt Falde [EMAIL PROTECTED] wrote: Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . Kurt Falde From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of HBooGz Sent: Saturday, July 29, 2006 5:39 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] R2 In-Place Upgrade bug ? Morning to all - I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence: The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g. telnet server ip 389 from the mail server works. \\serverip or servername brings up the shared printers and folders perfectly. outbound traffic and icmp works fine, inbound icmp returns a time out. scenario: Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2. connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/model installed new nic drivers and proset upgraded to R2. rebooted and noticed a ton of errors with services hanging upon boot. checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled. i disabled IPSEC and entered dword value for ProhibitIpSec - nothing i then enabled ICF configured exceptions - explicitly allowing ICMP, and still nothing. reset the TCP/ip stack and winsock using netsh, nothing servers has two nics, one of which is disabled. changed binding order so active is on top -- nothing reinstalled the binaries of windows 2003 sp1 and upgraded to r2 again -- nothing. i'm at a lost of ideas and sure could use to vast resources the contributors of this group may have or know of. Thanks, -- HBooGz:\ -- HBooGz:\
Re: [ActiveDir] R2 In-Place Upgrade bug ?
I dont think its SCW anymore. Admittedly I havent used SCW but I am aware of it. If policies were applied, the change logs will be in %windir%\security\msscw\ChangeConfigurationLogs. if I understand correctly, Port 445 must be open because your file shares and the like are accessible. According to GPO help docs that means ICMP is also allowed by the server. quoteNote: If any policy setting opens TCP port 445, Windows Firewall allows inbound echo requests, even if the Windows Firewall: Allow ICMP exceptions policy setting would block them. Policy settings that can open TCP port 445 include Windows Firewall: Allow file and printer sharing exception, Windows Firewall: Allow remote administration exception, and Windows Firewall: Define port exceptions. /quoteWhen you say you cant ping from the main office, are you talking of workstations/servers that belong to the same subnet of the DC they are pinging?I assume you did a trace to see ICMP coming into the server and whether its leaving the server. I'm curious now as to whats happening. M@On 7/29/06, HBooGz [EMAIL PROTECTED] wrote: I applied no post sp-1 fixes, but i would imagine it's worth a try.do you guys want to hear something even more mind-boggling ? i can ping the server from workstations outside the main office!!!i've remotely connected to workstations at our IPSEC vpns to test login times and email access,a nd pinged the problematic server just fine!!! arghhhMatheesha:Incoming connections i mean services that somehow are not defined to the server. I run a repadmin /replsum from another dc and it shows no errors. i run a dcdiag /s:problemserver with no problem. so it means that directory service traffic is allowed, but when i try to Dameware ( tcp port 6129) to the machine it times out, when i try to the ping the box i get nothing from the main office! i checked the IPSEC domain and Standard profile and made sure no IPSEC polocies were applied. if it's the SCW -- how do i look at it ?could it someway be my checkpoint firewall at the local site ? how in the world can it accept icmp from other workstations ( win2k pro) at my remote vpn sites ? On 7/29/06, Kurt Falde [EMAIL PROTECTED] wrote: Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . Kurt Falde From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of HBooGz Sent: Saturday, July 29, 2006 5:39 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] R2 In-Place Upgrade bug ? Morning to all - I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence: The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g. telnet server ip 389 from the mail server works. \\serverip or servername brings up the shared printers and folders perfectly. outbound traffic and icmp works fine, inbound icmp returns a time out. scenario: Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2. connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/model installed new nic drivers and proset upgraded to R2. rebooted and noticed a ton of errors with services hanging upon boot. checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled. i disabled IPSEC and entered dword value for ProhibitIpSec - nothing i then enabled ICF configured exceptions - explicitly allowing ICMP, and still nothing. reset the TCP/ip stack and winsock using netsh, nothing servers has two nics, one of which is disabled. changed binding order so active is on top -- nothing reinstalled the binaries of windows 2003 sp1 and upgraded to r2 again -- nothing. i'm at a lost of ideas and sure could use to vast resources the contributors of this group may have or know of. Thanks, -- HBooGz:\ -- HBooGz:\
Re: [ActiveDir] Migration without domain admin rights possible?
Thanks Guido, Really appreciate the time you have taken to write that systematic plan. :-) -- Kamlesh~Never confuse movement with action.~ On 7/28/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: 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 domain's 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 ParmarSent: 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.~
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 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. I'd love to look at said data with you if you're unclear as to what would fall in what bucket. Hope this helps. Please holler back with questions. ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al Mulnick Sent: Friday, July 28, 2006 10:34 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
RE: [ActiveDir] R2 In-Place Upgrade bug ?
Two quick questions- 1. Are you positive there are no IPsec policies applied to this machine? 2. Are you also positive that the machines from which you've been testing *also* have no IPsec policies in place? I can't think of a reason why this problem would surface only after you'd upgraded to R2, but it might not hurt to take a look with the IP security monitor just in case. As far as how to check whether or not it's a problem with the Security Configuration Wizard (which was introduced in Win2K3 SP1 and hasn't gone anywhere since it's quite new), you can read the log files as Matheesha mentioned, or you can runSCW against the server and it will allow you to rollback a previously applied policy (if applicable). If you try to rollback a policy and none was ever applied, it will tell you on about the third page of the wizard. Youcould then start over and select the option to create a new policy,which would show you the current configuration of the machine as part of the process of making the policy. If you're not sure where to find SCW, go to Add/Remove Programs, Add Windows Components to add or remove it, and when it's installed, it shows up in your Administrative Tools folder. Laura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of HBooGzSent: Saturday, July 29, 2006 10:54 AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] R2 In-Place Upgrade bug ? I applied no post sp-1 fixes, but i would imagine it's worth a try.do you guys want to hear something even more mind-boggling ?i can ping the server from workstations outside the main office!!!i've remotely connected to workstations at our IPSEC vpns to test login times and email access,a nd pinged the problematic server just fine!!! arghhhMatheesha:Incoming connections i mean services that somehow are not defined to the server. I run a repadmin /replsum from another dc and it shows no errors. i run a dcdiag /s:problemserver with no problem. so it means that directory service traffic is allowed, but when i try to Dameware ( tcp port 6129) to the machine it times out, when i try to the ping the box i get nothing from the main office! i checked the IPSEC domain and Standard profile and made sure no IPSEC polocies were applied. if it's the SCW -- how do i look at it ?could it someway be my checkpoint firewall at the local site ? how in the world can it accept icmp from other workstations ( win2k pro) at my remote vpn sites ? On 7/29/06, Kurt Falde [EMAIL PROTECTED] wrote: Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . Kurt Falde From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of HBooGzSent: Saturday, July 29, 2006 5:39 AMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] R2 In-Place Upgrade bug ? Morning to all -I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence:The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g. telnet server ip 389 from the mail server works. \\serverip or servername brings up the shared printers and folders perfectly.outbound traffic and icmp works fine, inbound icmp returns a time out.scenario:Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2.connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/modelinstalled new nic drivers and prosetupgraded to R2.rebooted and noticed a ton of errors with services hanging upon boot.checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled.i disabled IPSEC and entered dword value for ProhibitIpSec - nothingi then enabled ICF configured exceptions - explicitly allowing ICMP, and still nothing.reset the TCP/ip stack and winsock using netsh, nothing servers has two nics, one of which is disabled. changed binding order so active is on top -- nothingreinstalled the binaries of windows 2003 sp1 and upgraded to r2 again -- nothing.i'm at a lost of ideas and sure could use to vast resources the contributors of this group may have or know of. Thanks,-- HBooGz:\ -- HBooGz:\
Re: [ActiveDir] R2 In-Place Upgrade bug ?
Thanks Laura:I've never implemented IPSEC polices on my network, either in windoows 2000 nor here in windows 2003.so, you're saying to try to run the SCW to determine if a security policy is installed ? if not create one then roll-it back ? where can i find the ipsec monitor ?UPDATE* -- i've enabled to the windows firewall just to see what can be done with regard to icmp.i've used the netsh command to add a custom port that DAMEWARE remote uses. netsh firewall add portopening TCP 6129 dameware.once i added that, i was able to dameware into the box ( which i wasn't able to do previously)i then adjust the ICMP setting to allow ALL icmp. netsh firewall set icmpsetting ALL enableand allowed incomingnetsh firewall set icmpsetting 8 enableC:\netsh firewall show icmpsettingICMP configuration for Standard profile:Mode Type Description ---Enable 2 Allow outbound packet too bigEnable 3 Allow outbound destination unreachableEnable 4 Allow outbound source quench Enable 5 Allow redirectEnable 8 Allow inbound echo requestEnable 9 Allow inbound router requestEnable 11 Allow outbound time exceededEnable 12 Allow outbound parameter problem Enable 13 Allow inbound timestamp requestEnable 17 Allow inbound mask requestICMP configuration for Local Area Connection 7:Mode Type Description--- Enable 3 Allow outbound destination unreachableEnable 4 Allow outbound source quenchEnable 5 Allow redirectEnable 8 Allow inbound echo requestEnable 9 Allow inbound router request Enable 11 Allow outbound time exceededEnable 12 Allow outbound parameter problemEnable 13 Allow inbound timestamp requestEnable 17 Allow inbound mask requestthen - i disabled netsh opmode and enable's the exceptions on all the interfaces. I disabled the ICF service in the services console and restarted the machine. this is the output of the opmode syntax. C:\netsh firewall show opmodeDomain profile configuration:---Operational mode = DisableException mode = Enable Standard profile configuration:---Operational mode = DisableException mode = EnableLocal Area Connection 7 firewall configuration: ---Operational mode = DisableLocal Area Connection 8 firewall configuration:--- Operational mode = DisableThis is my config: Looks like i might want to disable the ICF using the domain profile in gpo, since it looks enabled ?C:\netsh firewall show config Domain profile configuration:---Operational mode = DisableException mode = EnableMulticast/broadcast response mode = Enable Notification mode = EnableService configuration for Domain profile:Mode Customized Name---Enable No File and Printer Sharing Port configuration for Domain profile:Port Protocol Mode Name---139 TCP Enable NetBIOS Session Service445 TCP Enable SMB over TCP 137 UDP Enable NetBIOS Name Service138 UDP Enable NetBIOS Datagram ServiceStandard profile configuration:---Operational mode = Disable Exception mode = EnableMulticast/broadcast response mode = EnableNotification mode = EnableService configuration for Standard profile:Mode Customized Name ---Enable No File and Printer SharingPort configuration for Standard profile:Port Protocol Mode Name--- 6129 TCP Enable dameware139 TCP Enable NetBIOS Session Service445 TCP Enable SMB over TCP137 UDP Enable NetBIOS Name Service138 UDP Enable NetBIOS Datagram Service ICMP configuration for Standard profile:Mode Type Description---Enable 2 Allow outbound packet too bigEnable 3 Allow outbound destination unreachable Enable 4 Allow outbound source quenchEnable 5 Allow redirectEnable 8 Allow inbound echo requestEnable 9 Allow inbound router requestEnable 11 Allow outbound time exceeded Enable 12 Allow outbound parameter problemEnable 13 Allow inbound timestamp requestEnable 17 Allow inbound mask requestLog configuration:--- File location = C:\WINNT\pfirewall.logMax file size = 4096 KBDropped packets = EnableConnections = DisableLocal Area Connection 7 firewall configuration:--- Operational mode = DisablePort configuration for Local Area Connection 7:Port Protocol Mode
RE: [ActiveDir] R2 In-Place Upgrade bug ?
No, I'm saying to run SCW first with the "rollback a previously applied policy" radio button selected to see if there was even one applied. Then, if there wasn't one applied, start the wizard over and begin the process of creating a new policy, but don't complete it. When you work through the wizard, it will actually show you all of the existing settings in place on the server. If nothing looks "off" at that point, then just cancel the wizard. If, however, you find that something is messed up, you may choose to either fix it manually or to actually create an SCW policy to fix it at that point. In fact, the SCW lets you take a policy you create and import it as a GPO, so if you wanted to be able to reproduce the settings, you could. The tool to do this is scwcmd; just type scwcmd /? at a command prompt and you'll get the options list. As far as whether or not this is a bug in the TCP/IP stack, I'll withhold judgement pending further testing. :-) Laura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of HBooGzSent: Saturday, July 29, 2006 2:01 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] R2 In-Place Upgrade bug ? Thanks Laura:I've never implemented IPSEC polices on my network, either in windoows 2000 nor here in windows 2003.so, you're saying to try to run the SCW to determine if a security policy is installed ? if not create one then roll-it back ? where can i find the ipsec monitor ?UPDATE* -- i've enabled to the windows firewall just to see what can be done with regard to icmp.i've used the netsh command to add a custom port that DAMEWARE remote uses. netsh firewall add portopening TCP 6129 dameware.once i added that, i was able to dameware into the box ( which i wasn't able to do previously)i then adjust the ICMP setting to allow ALL icmp.netsh firewall set icmpsetting ALL enableand allowed incomingnetsh firewall set icmpsetting 8 enableC:\netsh firewall show icmpsettingICMP configuration for Standard profile:Mode Type Description ---Enable 2 Allow outbound packet too bigEnable 3 Allow outbound destination unreachableEnable 4 Allow outbound source quench Enable 5 Allow redirectEnable 8 Allow inbound echo requestEnable 9 Allow inbound router requestEnable 11 Allow outbound time exceededEnable 12 Allow outbound parameter problem Enable 13 Allow inbound timestamp requestEnable 17 Allow inbound mask requestICMP configuration for Local Area Connection 7:Mode Type Description--- Enable 3 Allow outbound destination unreachableEnable 4 Allow outbound source quenchEnable 5 Allow redirectEnable 8 Allow inbound echo requestEnable 9 Allow inbound router request Enable 11 Allow outbound time exceededEnable 12 Allow outbound parameter problemEnable 13 Allow inbound timestamp requestEnable 17 Allow inbound mask requestthen - i disabled netsh opmode and enable's the exceptions on all the interfaces. I disabled the ICF service in the services console and restarted the machine. this is the output of the opmode syntax. C:\netsh firewall show opmodeDomain profile configuration:---Operational mode = DisableException mode = Enable Standard profile configuration:---Operational mode = DisableException mode = EnableLocal Area Connection 7 firewall configuration: ---Operational mode = DisableLocal Area Connection 8 firewall configuration:--- Operational mode = DisableThis is my config: Looks like i might want to disable the ICF using the domain profile in gpo, since it looks enabled ?C:\netsh firewall show configDomain profile configuration:---Operational mode = DisableException mode = EnableMulticast/broadcast response mode = Enable Notification mode = EnableService configuration for Domain profile:Mode Customized Name---Enable No File and Printer Sharing Port configuration for Domain profile:Port Protocol Mode Name---139 TCP Enable NetBIOS Session Service445 TCP Enable SMB over TCP 137 UDP Enable NetBIOS Name Service138 UDP Enable NetBIOS Datagram ServiceStandard profile configuration:---Operational mode = Disable Exception mode = EnableMulticast/broadcast response mode =
RE: [ActiveDir] R2 In-Place Upgrade bug ?
One amendment- even if you omit the /? and just type "scwcmd" at the command line, it will give you the syntax info. Oh, and I never answered your other question- IPsecmon was a command-line tool in 2000, but in Win2K3, it's an MMC snap-in, so just create an MMC and add the IP Security Monitor snap-in. Laura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of HBooGzSent: Saturday, July 29, 2006 2:01 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] R2 In-Place Upgrade bug ? Thanks Laura:I've never implemented IPSEC polices on my network, either in windoows 2000 nor here in windows 2003.so, you're saying to try to run the SCW to determine if a security policy is installed ? if not create one then roll-it back ? where can i find the ipsec monitor ?UPDATE* -- i've enabled to the windows firewall just to see what can be done with regard to icmp.i've used the netsh command to add a custom port that DAMEWARE remote uses. netsh firewall add portopening TCP 6129 dameware.once i added that, i was able to dameware into the box ( which i wasn't able to do previously)i then adjust the ICMP setting to allow ALL icmp.netsh firewall set icmpsetting ALL enableand allowed incomingnetsh firewall set icmpsetting 8 enableC:\netsh firewall show icmpsettingICMP configuration for Standard profile:Mode Type Description ---Enable 2 Allow outbound packet too bigEnable 3 Allow outbound destination unreachableEnable 4 Allow outbound source quench Enable 5 Allow redirectEnable 8 Allow inbound echo requestEnable 9 Allow inbound router requestEnable 11 Allow outbound time exceededEnable 12 Allow outbound parameter problem Enable 13 Allow inbound timestamp requestEnable 17 Allow inbound mask requestICMP configuration for Local Area Connection 7:Mode Type Description--- Enable 3 Allow outbound destination unreachableEnable 4 Allow outbound source quenchEnable 5 Allow redirectEnable 8 Allow inbound echo requestEnable 9 Allow inbound router request Enable 11 Allow outbound time exceededEnable 12 Allow outbound parameter problemEnable 13 Allow inbound timestamp requestEnable 17 Allow inbound mask requestthen - i disabled netsh opmode and enable's the exceptions on all the interfaces. I disabled the ICF service in the services console and restarted the machine. this is the output of the opmode syntax. C:\netsh firewall show opmodeDomain profile configuration:---Operational mode = DisableException mode = Enable Standard profile configuration:---Operational mode = DisableException mode = EnableLocal Area Connection 7 firewall configuration: ---Operational mode = DisableLocal Area Connection 8 firewall configuration:--- Operational mode = DisableThis is my config: Looks like i might want to disable the ICF using the domain profile in gpo, since it looks enabled ?C:\netsh firewall show configDomain profile configuration:---Operational mode = DisableException mode = EnableMulticast/broadcast response mode = Enable Notification mode = EnableService configuration for Domain profile:Mode Customized Name---Enable No File and Printer Sharing Port configuration for Domain profile:Port Protocol Mode Name---139 TCP Enable NetBIOS Session Service445 TCP Enable SMB over TCP 137 UDP Enable NetBIOS Name Service138 UDP Enable NetBIOS Datagram ServiceStandard profile configuration:---Operational mode = Disable Exception mode = EnableMulticast/broadcast response mode = EnableNotification mode = EnableService configuration for Standard profile:Mode Customized Name---Enable No File and Printer SharingPort configuration for Standard profile:Port Protocol Mode Name--- 6129 TCP Enable dameware139 TCP Enable NetBIOS Session Service445 TCP Enable SMB over TCP137 UDP Enable NetBIOS Name Service138 UDP Enable NetBIOS Datagram Service ICMP configuration for Standard profile:Mode Type Description---Enable
RE: [ActiveDir] ldp in ADAM-SP1
Yeah, extended rights like the one Guido mentions means that Full Control probably shouldn't have been named Not So Full Control as a real Full Control. I wonder if we will see a similar hack to support separation of Exchange attributes? The model is getting to be pretty bad. I vote for a new one. -- 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 2:37 AM To: ActiveDir@mail.activedir.org Subject: 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
RE: [ActiveDir] ldp in ADAM-SP1
Hmm I will probably see this tackled in later notes but after reading this one, the main thing that stuck in my head is don't worry about everything you can do. Work out what you are going to need delegated and then figure out how to do that piece. There were big debates when the delegation doc was being written for instance around how much enterprise admin stuff should truly be delegated? For instance, how many people do you really want creating and manipulating sites and subnets. That can impact so many things at so many levels it probably should be work filtered through a high level group that will have so many high level responsibilities that they should be Enterprise Admins anyway. If I were to delegate any of the subnet/site type stuff it would only be threw some sort of provisioning process that I could assign business rules too for that exact reason. I don't care if the Network group knows all about the subnetting info and they are responsible for it, I wouldn't let them tweak my AD for the subnet info because it impacts at a minimum my replication topology. As we move forward it will impact more as it sounds like Exchange 12 will be using the topology AD has configured for its routing and I have heard more than one argument between SMS admins and AD Admins over topology already. Oh for the record, when it comes down to it, the AD Topology is for managing my replication. If something else can leverage what I have in place, bully for it, but I am not going to design my topology such that the apps benefit and my replication feels pain or even makes it more painful for me to manage and never will application admins get access to sites and subnets in an AD I manage. That is a recipe for AD disaster. 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 Matheesha Weerasinghe Sent: Tuesday, July 25, 2006 3:34 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 Wow, Thanks you so much for the detailed info guys. Basically my goal is quite simple. At least it is in my head. What I want to do, is to go through the entire case study given in the AD delegation whitepaper, and do all of that permissions configuration entirely at command line (where possible). I am willing to use the delegation wizard to some extent, but as I am configuring quite a lot of permissions for an AD design I am involved in, I would rather avoid having to use GUI tools for this. You see, I am going to end up as been a very privileged service administrator and data administrator once my proposed AD design model is in place. I expect I will be making some endeavour to train sufficiently capable people in doing this. But I dont plan to spoon feed. I want the guys to know to a decent level ACL'ing and if not, do their research. At least on an adhoc basis. Then once they understand whats involved, they can go ahead and add/modify/delete ACE's , revoke perms, define new roles etc... Reading this delegation doc has made me believe I can configure an extremely secure delegation model where each role can be given just enough to do that role. The tricky bit is the matching a trusted and appropriately skilled person 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,
RE: [ActiveDir] ldp in ADAM-SP1
I am curious about this statement While you can use the command line tools as much as possible, as joe and Guido both pointed out, consider rolling your own scripts if you absolutely cannot do what you *need* to do at the GUI. In general, scripts are more dangerous than the command line tools because there are a lot of screwups you can make in a script that a tool may not make because hopefully a full blown tool writer understand the permissioning model and the dev work behind it than a script writer. It is quite easy to use a script and to add 30 duplicate ACEs to an ACL. I can't count the number of times I have seen things like that. There is no guarantee that a commandline tool won't do the same but there are fewer and hopefully more experienced people writing command line tools than scripts. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Tuesday, July 25, 2006 9:19 AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] ldp in ADAM-SP1 I wholeheartedly applaud the effort being put into this. That said, I urge you to reconsider your administrative model and favor as much simplicity as is possible. Why? Because the best laid plans of mice and architects and all that. "The tricky bit is the matching a trusted andappropriately skilled person to the relevant role." That makes me laugh and cringe at the same time. Yes, it is very difficult to find that "perfect match" but at the same time I think a design should take that into account where possible. That's a design philosophy and I won't debate that for this thread. But I would caution you that any design that has the people intricately relied upon is going to have a failure point at some point when you least can tolerate it. While you can use the command line tools as much as possible, as joe and Guido both pointed out, consider rolling your own scripts if you absolutely cannot do what you *need* to do at the GUI. But remember you can really really really^^ hurt yourself with security permissions. Believe me, it can be ugly and it can be the undoing. Two thoughts consider as you walk through the design: 1) You should never try to solve wetware issues with software or hardware. 2) Complexity is the anti-security. Best of luck. On 7/25/06, Matheesha Weerasinghe [EMAIL PROTECTED] wrote: Wow,Thanks you so much for the detailed info guys. Basically my goal isquite simple. At least it is in my head. What I want to do, is to go through the entire case study given in the AD delegation whitepaper,and do all of that permissions configuration entirely at command line(where possible). I am willing to use the delegation wizard to someextent, but as I am configuring quite a lot of permissions for an AD design I am involved in, I would rather avoid having to use GUI toolsfor this.You see, I am going to end up as been a very privileged serviceadministrator and data administrator once my proposed AD design model is in place. I expect I will be making some endeavour to trainsufficiently capable people in doing this. But I dont plan to spoonfeed. I want the guys to know to a decent level ACL'ing and if not, dotheir research. At least on an adhoc basis. Then once they understand whats involved, they can go ahead and add/modify/delete ACE's , revokeperms, define new roles etc...Reading this delegation doc has made me believe I can configure anextremely secure delegation model where each role can be given just enough to do that role. The tricky bit is the matching a trusted andappropriately skilled person to the relevant role.So you see, as there is a lot involved and this is a biginfrastructure to attempt to administer perms for 20,000 users plus many OUs used to organise users based on the business unit (at least adozen in each geographical hub) they work in and the site (we havemore than a 40 geographical hubs and 1000 satellite sites) they arelocated 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 notbe big as in Fortune 5 ADs. But its the biggest I've had the privilegeto 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 alittle miffed when I have to swap between several tools to do what Ineed 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 thentry this. If all else fails script "I admit I was ranting a bit when asking why is this named and likesuch 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 commandline or GUI
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 FleischmanSent: Sat 7/29/2006 11:22 AMTo: ActiveDir@mail.activedir.orgSubject: 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 MulnickSent: Friday, July 28, 2006 3:28 PMTo: ActiveDir@mail.activedir.orgSubject: 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 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. I'd love to look at said data with you if you're 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 MulnickSent: Friday, July 28,
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 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
RE: [ActiveDir] ldp in ADAM-SP1
Granular ACLing is much preferred to say just giving out account operator or domain admin to people In general though, you need to have a good plan as to what you are giving out and why. As I get older and see more and more deployments I am more and more against native delegation and more and more for provisioning. If MSFT was going to step up and give us business rules so we can define the kind of info that could be set on values then I would not be as against native delegation. The biggest problem I tend to run into anymore is companies who give out FULL CONTROL (or actually NSFC[1]) and then not having a clue what it really means and getting confused why when they add Exchange or some other application that adds attributes or functionality and why some local site admin can read every one of their user's email or other things. This also translates to local site admins overriding centralized application support settings for various things, especially Exchange, think quotas, etc which can be overridden at the user level. Next biggest problem is a huge complicated amount of delegation done to multiple groups such that you run dsacls on an OU or other object and the ACL list scrolls by for 11 screens... This has tremendous impact on your performance and if 2K on the size of the DIT as well. One company I pushed to clean up their ACLs removed quite a few (they had over 100 to start with) and a query I would run that used to take over 90 minutes to run took less than 50 after the cleanup. That is substantial. joe [1] Not So Full Control - I am copyrighting that... -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Tuesday, July 25, 2006 3:18 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 Thanks to Al and Guido for your further input. Even though it may seem pretty obvious, I would like to know of any horror stories due to AD ACL'ing if possible. The reason is Al's comments have made me take a much more cautious approach to ACL'ing. I get the feeling that even though the granular feature is there, if there arent enoug people with the correct skill level available to maintain it, then it shouldnt be pursued. I hope I can get that skill and that is one fo the goals here. But I may not be here all the time. So any stories from anyone ? M@ On 7/25/06, Al Mulnick [EMAIL PROTECTED] wrote: I wholeheartedly applaud the effort being put into this. That said, I urge you to reconsider your administrative model and favor as much simplicity as is possible. Why? Because the best laid plans of mice and architects and all that. The tricky bit is the matching a trusted and appropriately skilled person to the relevant role. That makes me laugh and cringe at the same time. Yes, it is very difficult to find that perfect match but at the same time I think a design should take that into account where possible. That's a design philosophy and I won't debate that for this thread. But I would caution you that any design that has the people intricately relied upon is going to have a failure point at some point when you least can tolerate it. While you can use the command line tools as much as possible, as joe and Guido both pointed out, consider rolling your own scripts if you absolutely cannot do what you *need* to do at the GUI. But remember you can really really really^^ hurt yourself with security permissions. Believe me, it can be ugly and it can be the undoing. Two thoughts consider as you walk through the design: 1) You should never try to solve wetware issues with software or hardware. 2) Complexity is the anti-security. Best of luck. On 7/25/06, Matheesha Weerasinghe [EMAIL PROTECTED] wrote: Wow, Thanks you so much for the detailed info guys. Basically my goal is quite simple. At least it is in my head. What I want to do, is to go through the entire case study given in the AD delegation whitepaper, and do all of that permissions configuration entirely at command line (where possible). I am willing to use the delegation wizard to some extent, but as I am configuring quite a lot of permissions for an AD design I am involved in, I would rather avoid having to use GUI tools for this. You see, I am going to end up as been a very privileged service administrator and data administrator once my proposed AD design model is in place. I expect I will be making some endeavour to train sufficiently capable people in doing this. But I dont plan to spoon feed. I want the guys to know to a decent level ACL'ing and if not, do their research. At least on an adhoc basis. Then once they understand whats involved, they can go ahead and add/modify/delete ACE's , revoke perms, define new roles etc... Reading this delegation doc has made me believe I can configure an
RE: [ActiveDir] ldp in ADAM-SP1
Create a plan that allows for flexible delegation and proper naming of roles but don't build the actual delegation until it is needed. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Wednesday, July 26, 2006 3:30 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 Thanks Guido. That helps a lot. I was going to create the role structure but leave them unpopulated and do most of the work myself. I.e I am all roles!! I was then going to populate them as and when I found skilled and trusted chaps. I'll keep it very simple now. Cheers M@ P.S. Thanks again to everyone that read and responded. On 7/26/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: well, do as you should always do to ensure that your systems are maintainable: keep it simple! Don't introduce extra complexity if you don't require it. For AD ACLing this means, don't introduce roles and permissions for users, if you do not need that role - there is certainly no need to implement all the roles that are described in the delegation whitepaper to maintain a stable AD infrastructure. most ACLing issues that I have come across was in companies that granted their delegated admins the rights to create OUs underneath their location specific OU - soon afterwards they had an AD structure with OUs and permissions that looked like a badly managed file-server... so the issue is not so much setting ACLs in AD (which as discussed can be a complex task to do right, depending on your needs), but more controlling who is allowed to set ACLs. This should be done centrally by domain and/or enterprise admins. As a rule of thumb you should not grant any non-domain or enterprise admin the rights to create OUs and also limit the rights to create any other objects (especially groups) to very few delegated admins. Less critical is delegating the ability to manage existing objects (e.g. to reset PW of user, mail-enable users and groups, change membership of groups, etc). I also consider the rights to create computer objects as low risk (which is usually required by local desktop admins in branch offices). /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Tuesday, July 25, 2006 9:18 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 Thanks to Al and Guido for your further input. Even though it may seem pretty obvious, I would like to know of any horror stories due to AD ACL'ing if possible. The reason is Al's comments have made me take a much more cautious approach to ACL'ing. I get the feeling that even though the granular feature is there, if there arent enoug people with the correct skill level available to maintain it, then it shouldnt be pursued. I hope I can get that skill and that is one fo the goals here. But I may not be here all the time. So any stories from anyone ? M@ On 7/25/06, Al Mulnick [EMAIL PROTECTED] wrote: I wholeheartedly applaud the effort being put into this. That said, I urge you to reconsider your administrative model and favor as much simplicity as is possible. Why? Because the best laid plans of mice and architects and all that. The tricky bit is the matching a trusted and appropriately skilled person to the relevant role. That makes me laugh and cringe at the same time. Yes, it is very difficult to find that perfect match but at the same time I think a design should take that into account where possible. That's a design philosophy and I won't debate that for this thread. But I would caution you that any design that has the people intricately relied upon is going to have a failure point at some point when you least can tolerate it. While you can use the command line tools as much as possible, as joe and Guido both pointed out, consider rolling your own scripts if you absolutely cannot do what you *need* to do at the GUI. But remember you can really really really^^ hurt yourself with security permissions. Believe me, it can be ugly and it can be the undoing. Two thoughts consider as you walk through the design: 1) You should never try to solve wetware issues with software or hardware. 2) Complexity is the anti-security. Best of luck. On 7/25/06, Matheesha Weerasinghe [EMAIL PROTECTED] wrote: Wow, Thanks you so much for the detailed info guys. Basically my goal is quite simple. At least it is in my head. What I want to do, is to go through the entire case study given in the AD delegation whitepaper, and do all of that permissions configuration entirely at command line (where possible). I am willing to use the delegation wizard to some extent, but as I am configuring quite a lot of permissions for an AD
Re: [ActiveDir] R2 In-Place Upgrade bug ?
Laura --I'm running through the SCW and am not sure at which point do you want me to look at that determines if something is off. As i run through the SCW, i imagine the View needs to be set on Installed Options, which gives me an idea as to what is on the machine. It runs through the security config databse and then i have an option to View Configuration Database. Once i view that, there are almost every possible microsoft app avaible for the server. I go to the Windows firewall application and it omes up with a status of Installed, enabled -- this is defintely off because the service is disabled and is not applied to any adapters ? PS. I didn't have a rollback file to proceed.Then there is the role-based config wizardSecurity config wizardWhere i have the option to uncheck the Windows firewalli have the options to skip the windows firewall and registry settings and audit policy, which effectively disables them on the machine And then the changed services , which has a lot of services listed and ones that it can disable -- in particular: Intersite messaging and RPC locator ( unnecessary on a dc ? )how should i proceed? On 7/29/06, Laura A. Robinson [EMAIL PROTECTED] wrote: One amendment- even if you omit the /? and just type scwcmd at the command line, it will give you the syntax info. Oh, and I never answered your other question- IPsecmon was a command-line tool in 2000, but in Win2K3, it's an MMC snap-in, so just create an MMC and add the IP Security Monitor snap-in. Laura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of HBooGzSent: Saturday, July 29, 2006 2:01 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] R2 In-Place Upgrade bug ? Thanks Laura:I've never implemented IPSEC polices on my network, either in windoows 2000 nor here in windows 2003.so, you're saying to try to run the SCW to determine if a security policy is installed ? if not create one then roll-it back ? where can i find the ipsec monitor ?UPDATE* -- i've enabled to the windows firewall just to see what can be done with regard to icmp.i've used the netsh command to add a custom port that DAMEWARE remote uses. netsh firewall add portopening TCP 6129 dameware.once i added that, i was able to dameware into the box ( which i wasn't able to do previously)i then adjust the ICMP setting to allow ALL icmp.netsh firewall set icmpsetting ALL enableand allowed incomingnetsh firewall set icmpsetting 8 enableC:\netsh firewall show icmpsettingICMP configuration for Standard profile:Mode Type Description ---Enable 2 Allow outbound packet too bigEnable 3 Allow outbound destination unreachableEnable 4 Allow outbound source quench Enable 5 Allow redirectEnable 8 Allow inbound echo requestEnable 9 Allow inbound router requestEnable 11 Allow outbound time exceededEnable 12 Allow outbound parameter problem Enable 13 Allow inbound timestamp requestEnable 17 Allow inbound mask requestICMP configuration for Local Area Connection 7:Mode Type Description--- Enable 3 Allow outbound destination unreachableEnable 4 Allow outbound source quenchEnable 5 Allow redirectEnable 8 Allow inbound echo requestEnable 9 Allow inbound router request Enable 11 Allow outbound time exceededEnable 12 Allow outbound parameter problemEnable 13 Allow inbound timestamp requestEnable 17 Allow inbound mask requestthen - i disabled netsh opmode and enable's the exceptions on all the interfaces. I disabled the ICF service in the services console and restarted the machine. this is the output of the opmode syntax. C:\netsh firewall show opmodeDomain profile configuration:---Operational mode = DisableException mode = Enable Standard profile configuration:---Operational mode = DisableException mode = EnableLocal Area Connection 7 firewall configuration: ---Operational mode = DisableLocal Area Connection 8 firewall configuration:--- Operational mode = DisableThis is my config: Looks like i might want to disable the ICF using the domain profile in gpo, since it looks enabled ?C:\netsh firewall show configDomain profile configuration:---Operational mode = DisableException mode = EnableMulticast/broadcast response mode = Enable Notification mode = EnableService configuration for Domain profile:Mode Customized Name---Enable No
Re: [ActiveDir] Read-Only Domain Controller and Server Core
Ah see but I don't like mushrooms. Stupid question alert? What's the specs on this? We've always joked that in SBSland with our everything including the kitchen sink on our DCs if there was a way to make the DC services like on a linksys sized box that attached to the file/printer/email/kitchen sink box that would remove a lot of OHMYGOSHYOUDOWHATTOYOURDC! that we get from the enterprise crowd. Are there any embedded OS like plans for this server core RODC? Crawford, Scott wrote: 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 don’t know your enterprise or your threat model. As such, there’s 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 I’ll disagree with, there are some enterprises that will do this, but that’s 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] mailto:[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, kinda…you 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.
RE: [ActiveDir] Can I add an index in AD using an LDIF file?
Title: Can I add an index in AD using an LDIF file?
Unlike some other LDAP directories, the MSFT guys had the
brilliant insight to actually put the indexing info for an attribute as an
actual attribute of the attribute definition in the schema so you can do this
with LDIF and so it takes effect on the fly. Compare this to modifying the
slapd.conf file and restarting the directory service.
Heck I usually use admod to index attributes in AD and
ADAM, but then I do most of my schemaadds/mods/deleteswith admod.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]Sent: Friday, July 28, 2006 10:46
AMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Can
I add an index in AD using an LDIF file?
I realise I could do this via the UI but I want to
create a single LDIF which will:
Add new attributes
Make new attributes available to User class
Add new indexes
The last point evades me so far and the RFC appears
to indicate that this is not supported(?)
Any ideas?
neil
PLEASE READ: The
information contained in this email is confidential and
intended for the
named recipient(s) only. If you are not an intended
recipient of this
email please notify the sender immediately and delete your
copy from your
system. You must not copy, distribute or take any further
action in reliance
on it. Email is not a secure method of communication and
Nomura International
plc ('NIplc') will not, to the extent permitted by law,
accept
responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence
of any virus, worm or similar malicious or disabling
code in, this
message or any attachment(s) to it. If verification of this
email is sought then
please request a hard copy. Unless otherwise stated
this email: (1) is
not, and should not be treated or relied upon as,
investment research;
(2) contains views or opinions that are solely those of
the author and do
not necessarily represent those of NIplc; (3) is intended
for informational
purposes only and is not a recommendation, solicitation or
offer to buy or sell
securities or related financial instruments. NIplc
does not provide
investment services to private customers. Authorised and
regulated by the
Financial Services Authority. Registered in England
no. 1550505 VAT No.
447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A
member of the Nomura group of companies.
RE: [ActiveDir] Query on Security Groups
The builtin groups kept in the builtin container are some of groups/security principals with SIDs that do not have domain/machine affinity (see below). I cannot think of any real reason for Microsoft tosegregate them like that other than for logical separation. G:\adfind -default -rb cn=builtin objectsid AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED]) March 2006 Using server: r2dc2.test.loc:389Directory: Windows Server 2003Base DN: cn=builtin,DC=test,DC=loc dn:CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32 dn:CN=Remote Desktop Users,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-555 dn:CN=Network Configuration Operators,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-556 dn:CN=Performance Monitor Users,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-558 dn:CN=Performance Log Users,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-559 dn:CN=Distributed COM Users,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-562 dn:CN=Incoming Forest Trust Builders,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-557 dn:CN=Terminal Server License Servers,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-561 dn:CN=Users,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-545 dn:CN=Guests,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-546 dn:CN=Pre-Windows 2000 Compatible Access,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-554 dn:CN=Windows Authorization Access Group,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-560 dn:CN=Print Operators,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-550 dn:CN=Account Operators,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-548 dn:CN=Administrators,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-544 dn:CN=Replicator,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-552 dn:CN=Server Operators,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-549 dn:CN=Backup Operators,CN=Builtin,DC=test,DC=locobjectSid: S-1-5-32-551 18 Objects returned -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank AbagnaleSent: Thursday, July 27, 2006 4:56 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Query on Security Groups I was just curious what the different security groups were in each container, wondered if the users container was the default for users, why have various security groups in there as well. Why not have them all residing in the one container. Thanks for responding Al Mulnick [EMAIL PROTECTED] wrote: Interesting CN=Users = default container for users CN=Builtin = default container for builtin objects such as administrators. IIRC. Domain Admins vs. Administrators? It's a toss up because either can become the other. By default however, domain admins has rights to more objects because by default the domain admins has the ability to edit GPO and is added to the member wkstns and server administrators group on joining the domain. What makes you ask? On 7/27/06, Frank Abagnale [EMAIL PROTECTED] wrote: Hi, I have two queries: 1. What is the difference between the Users Container and Builtin Container off the root of AD. What do the different groups do? 2. What is the difference between the Administrators group and the Domain Admins group. which has higher permissions within the forest? thanks Frank Do you Yahoo!?Get on board. You're invited to try the new Yahoo! Mail Beta. Do you Yahoo!?Get on board. You're invited to try the new Yahoo! Mail Beta.
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] Exchange rollout - How much larger does NTDS.DIT become?
Title: Exchange rollout - How much larger does NTDS.DIT become? 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, GuidoSent: Friday, July 28, 2006 4:41 AMTo: ActiveDir@mail.activedir.orgSubject: 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 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 RMSent: Thursday, July 27, 2006 6:46 PMTo: ActiveDir@mail.activedir.orgSubject: [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
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] Read-Only Domain Controller and Server Core
IMHO it would be hard to ship an appliance for an application which requires designing the hardware around the scenario... 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: Saturday, July 29, 2006 2:50 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core Ah see but I don't like mushrooms. Stupid question alert? What's the specs on this? We've always joked that in SBSland with our everything including the kitchen sink on our DCs if there was a way to make the DC services like on a linksys sized box that attached to the file/printer/email/kitchen sink box that would remove a lot of OHMYGOSHYOUDOWHATTOYOURDC! that we get from the enterprise crowd. Are there any embedded OS like plans for this server core RODC? Crawford, Scott wrote: 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 clearthe 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 don't know your enterprise or your threat model. As such, there's really no good choicewe 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 I'll disagree with, there are some enterprises that will do this, but that's 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] mailto:[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, kinda...you 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 clientsthen 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
Re: [ActiveDir] R2 In-Place Upgrade bug ?
I would definitely get the tcpip.sys hotfixes applied as this sounds very symptomatic of ms05-019 issues. Kurt Falde Sent from my Windows Mobile Phone -Original Message- From: HBooGz[EMAIL PROTECTED] Sent: 7/29/06 10:58:58 AM To: ActiveDir@mail.activedir.orgActiveDir@mail.activedir.org Subject: Re: [ActiveDir] R2 In-Place Upgrade bug ? I applied no post sp-1 fixes, but i would imagine it's worth a try. do you guys want to hear something even more mind-boggling ? i can ping the server from workstations outside the main office!!! i've remotely connected to workstations at our IPSEC vpns to test login times and email access,a nd pinged the problematic server just fine!!! arghhh Matheesha: Incoming connections i mean services that somehow are not defined to the server. I run a repadmin /replsum from another dc and it shows no errors. i run a dcdiag /s:problemserver with no problem. so it means that directory service traffic is allowed, but when i try to Dameware ( tcp port 6129) to the machine it times out, when i try to the ping the box i get nothing from the main office! i checked the IPSEC domain and Standard profile and made sure no IPSEC polocies were applied. if it's the SCW -- how do i look at it ? could it someway be my checkpoint firewall at the local site ? how in the world can it accept icmp from other workstations ( win2k pro) at my remote vpn sites ? On 7/29/06, Kurt Falde [EMAIL PROTECTED] wrote: Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . *Kurt Falde* -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *HBooGz *Sent:* Saturday, July 29, 2006 5:39 AM *To:* ActiveDir@mail.activedir.org *Subject:* [ActiveDir] R2 In-Place Upgrade bug ? Morning to all - I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence: The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g. telnet *server ip* 389 from the mail server works. \\*serverip or servername *brings up the shared printers and folders perfectly. outbound traffic and icmp works fine, inbound icmp returns a time out. scenario: Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2. connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/model installed new nic drivers and proset upgraded to R2. rebooted and noticed a ton of errors with services hanging upon boot. checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled. i disabled IPSEC and entered dword value for ProhibitIpSec - nothing i then enabled ICF configured exceptions - explicitly allowing ICMP, and still nothing. reset the TCP/ip stack and winsock using netsh, nothing servers has two nics, one of which is disabled. changed binding order so active is on top -- nothing reinstalled the binaries of windows 2003 sp1 and upgraded to r2 again -- nothing. i'm at a lost of ideas and sure could use to vast resources the contributors of this group may have or know of. Thanks, -- HBooGz:\ -- HBooGz:\ 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] [OT] Can I add an index in AD using an LDIF file?
LOL. This was catch up week. I took it off from work and
ran around the house getting stuff fixed up etc and was only so so watching
email. I also went to Cedar Point but that was quite the let down. It has gotten
pretty run down and the clientele is interesting nowto say the least. Kind
of sad as it can be an incredibly fun place.Anyway, when my task list in
OneNote starts causing memory paging on my PC I figure I need to do a little
catchup and take off time so I don't have any distractions so I can do so.
Now I am sitting here, resting up from putting down some
more grass seed and fertilizer in the 98 degree (37C for you metric folks)
weather sucking down a rootbeer float and not looking forward to going back to
work on Monday. I need to be independently wealthy already. I need to go find
and adopt some rich parents.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Al
MulnickSent: Friday, July 28, 2006 11:13 AMTo:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Can I add an
index in AD using an LDIF file?
Hey, I can post this one ahead of joe? joe must be busy or somethin'
:)
I believe this is what you're looking for:
http://rallenhome.com/books/adcookbook/code.html
(see chapter 10 section for the vbs, ldif, and perl
sections)
On 7/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
I realise I could do this via the UI but I want to
create a single LDIF which will:
Add new attributes
Make new attributes available to User
class
Add new indexes
The last point evades me so far and the RFC appears
to indicate that this is not supported(?)
Any ideas?
neil
PLEASE READ: The information contained in
this email is confidential and
intended for the named recipient(s) only.
If you are not an intended
recipient of this email please notify the
sender immediately and delete your
copy from your system. You must not copy,
distribute or take any further
action in reliance on it. Email is not a
secure method of communication and
Nomura International plc ('NIplc') will
not, to the extent permitted by law,
accept responsibility or liability for (a)
the accuracy or completeness of,
or (b) the presence of any virus, worm or
similar malicious or disabling
code in, this message or any attachment(s)
to it. If verification of this
email is sought then please request a hard
copy. Unless otherwise stated
this email: (1) is not, and should not be
treated or relied upon as,
investment research; (2) contains views or
opinions that are solely those of
the author and do not necessarily represent
those of NIplc; (3) is intended
for informational purposes only and is not
a recommendation, solicitation or
offer to buy or sell securities or related
financial instruments. NIplc
does not provide investment services to
private customers. Authorised and
regulated by the Financial Services
Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered
Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura
group of companies.
RE: [ActiveDir] ldp in ADAM-SP1
To explain what Guido is saying. So buy the book now!!! Don't wait until it is too late to help you out!!! Thanks Guido, nice angle, I hadn't thought of that one... For retirement money I would consider specifying some other ways it can be done that will work on later OSes... :o) It has to be enough retirement money to buy an island or something though, because if I keep talking, ~Eric will probably try to come find and kill me. Not because he told me how to do any of it, but because he is very clear on the fact that setting cat-1 attributes to confidential is a strictly untested condition as I am quite clear on that point in the book as well. :) Personally, I think everything around confidential bits is a bad idea. 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: Saturday, July 29, 2006 4:22 PM To: ActiveDir@mail.activedir.org Subject: 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
Re: [ActiveDir] R2 In-Place Upgrade bug ?
I applied the related to article ending with MS06-007.mspx .do you happen to have the hotfix for the other article ?On 7/29/06, Kurt Falde [EMAIL PROTECTED] wrote:I would definitely get the tcpip.sys hotfixes applied as this sounds very symptomatic of ms05-019 issues. Kurt FaldeSent from my Windows Mobile Phone-Original Message-From: HBooGz[EMAIL PROTECTED]Sent: 7/29/06 10:58:58 AMTo: ActiveDir@mail.activedir.orgActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] R2 In-Place Upgrade bug ? I applied no post sp-1 fixes, but i would imagine it's worth a try.do you guys want to hear something even more mind-boggling ?i can ping the server from workstations outside the main office!!! i've remotely connected to workstations at our IPSEC vpns to test logintimes and email access,a nd pinged the problematic server just fine!!!arghhhMatheesha:Incoming connections i mean services that somehow are not defined to the server. I run a repadmin /replsum from another dc and it shows no errors. irun a dcdiag /s:problemserver with no problem. so it means that directoryservice traffic is allowed, but when i try to Dameware ( tcp port 6129) to the machine it times out, when i try to the ping the box i get nothing fromthe main office!i checked the IPSEC domain and Standard profile and made sure no IPSECpolocies were applied.if it's the SCW -- how do i look at it ? could it someway be my checkpoint firewall at the local site ? how in theworld can it accept icmp from other workstations ( win2k pro) at my remotevpn sites ?On 7/29/06, Kurt Falde [EMAIL PROTECTED] wrote:Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . *Kurt Falde* -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] *On Behalf Of *HBooGz *Sent:* Saturday, July 29, 2006 5:39 AM *To:* ActiveDir@mail.activedir.org *Subject:* [ActiveDir] R2 In-Place Upgrade bug ? Morning to all - I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence: The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g. telnet *server ip* 389 from the mail server works. \\*serverip or servername *brings up the shared printers and folders perfectly. outbound traffic and icmp works fine, inbound icmp returns a time out. scenario: Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2. connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/model installed new nic drivers and proset upgraded to R2. rebooted and noticed a ton of errors with services hanging upon boot. checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled. i disabled IPSEC and entered dword value for ProhibitIpSec - nothing i then enabled ICF configured exceptions - explicitly allowing ICMP, and still nothing. reset the TCP/ip stack and winsock using netsh, nothing servers has two nics, one of which is disabled. changed binding order so active is on top -- nothing reinstalled the binaries of windows 2003 sp1 and upgraded to r2 again -- nothing. i'm at a lost of ideas and sure could use to vast resources the contributors of this group may have or know of. Thanks, -- HBooGz:\--HBooGz:\List info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx-- HBooGz:\
RE: [ActiveDir] R2 In-Place Upgrade bug ?
http://support.microsoft.com/kb/898060 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kurt Falde Sent: Saturday, July 29, 2006 5:19 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] R2 In-Place Upgrade bug ? I would definitely get the tcpip.sys hotfixes applied as this sounds very symptomatic of ms05-019 issues. Kurt Falde Sent from my Windows Mobile Phone -Original Message- From: HBooGz[EMAIL PROTECTED] Sent: 7/29/06 10:58:58 AM To: ActiveDir@mail.activedir.orgActiveDir@mail.activedir.org Subject: Re: [ActiveDir] R2 In-Place Upgrade bug ? I applied no post sp-1 fixes, but i would imagine it's worth a try. do you guys want to hear something even more mind-boggling ? i can ping the server from workstations outside the main office!!! i've remotely connected to workstations at our IPSEC vpns to test login times and email access,a nd pinged the problematic server just fine!!! arghhh Matheesha: Incoming connections i mean services that somehow are not defined to the server. I run a repadmin /replsum from another dc and it shows no errors. i run a dcdiag /s:problemserver with no problem. so it means that directory service traffic is allowed, but when i try to Dameware ( tcp port 6129) to the machine it times out, when i try to the ping the box i get nothing from the main office! i checked the IPSEC domain and Standard profile and made sure no IPSEC polocies were applied. if it's the SCW -- how do i look at it ? could it someway be my checkpoint firewall at the local site ? how in the world can it accept icmp from other workstations ( win2k pro) at my remote vpn sites ? On 7/29/06, Kurt Falde [EMAIL PROTECTED] wrote: Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . *Kurt Falde* -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *HBooGz *Sent:* Saturday, July 29, 2006 5:39 AM *To:* ActiveDir@mail.activedir.org *Subject:* [ActiveDir] R2 In-Place Upgrade bug ? Morning to all - I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence: The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g. telnet *server ip* 389 from the mail server works. \\*serverip or servername *brings up the shared printers and folders perfectly. outbound traffic and icmp works fine, inbound icmp returns a time out. scenario: Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2. connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/model installed new nic drivers and proset upgraded to R2. rebooted and noticed a ton of errors with services hanging upon boot. checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled. i disabled IPSEC and entered dword value for ProhibitIpSec - nothing i then enabled ICF configured exceptions - explicitly allowing ICMP, and still nothing. reset the TCP/ip stack and winsock using netsh, nothing servers has two nics, one of which is disabled. changed binding order so active is on top -- nothing reinstalled the binaries of windows 2003 sp1 and upgraded to r2 again -- nothing. i'm at a lost of ideas and sure could use to vast resources the contributors of this group may have or know of. Thanks, -- HBooGz:\ -- HBooGz:\ 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] R2 In-Place Upgrade bug ?
Kurt -I applied the later of the tcpip.sys updates ( the one availble to download) and it updated the tcpip.sys file with a newer timestamp than what the other article would have given it -- is it even worth it ? at this point, i wouldn't be surprised.Thanks guys, i think we're almost there..On 7/29/06, HBooGz [EMAIL PROTECTED] wrote:I applied the related to article ending with MS06-007.mspx .do you happen to have the hotfix for the other article ?On 7/29/06, Kurt Falde [EMAIL PROTECTED] wrote:I would definitely get the tcpip.sys hotfixes applied as this sounds very symptomatic of ms05-019 issues. Kurt FaldeSent from my Windows Mobile Phone-Original Message-From: HBooGz [EMAIL PROTECTED]Sent: 7/29/06 10:58:58 AMTo: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] R2 In-Place Upgrade bug ? I applied no post sp-1 fixes, but i would imagine it's worth a try.do you guys want to hear something even more mind-boggling ?i can ping the server from workstations outside the main office!!! i've remotely connected to workstations at our IPSEC vpns to test logintimes and email access,a nd pinged the problematic server just fine!!!arghhhMatheesha:Incoming connections i mean services that somehow are not defined to the server. I run a repadmin /replsum from another dc and it shows no errors. irun a dcdiag /s:problemserver with no problem. so it means that directoryservice traffic is allowed, but when i try to Dameware ( tcp port 6129) to the machine it times out, when i try to the ping the box i get nothing fromthe main office!i checked the IPSEC domain and Standard profile and made sure no IPSECpolocies were applied.if it's the SCW -- how do i look at it ? could it someway be my checkpoint firewall at the local site ? how in theworld can it accept icmp from other workstations ( win2k pro) at my remotevpn sites ?On 7/29/06, Kurt Falde [EMAIL PROTECTED] wrote:Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . *Kurt Falde* -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] *On Behalf Of *HBooGz *Sent:* Saturday, July 29, 2006 5:39 AM *To:* ActiveDir@mail.activedir.org *Subject:* [ActiveDir] R2 In-Place Upgrade bug ? Morning to all - I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence: The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g. telnet *server ip* 389 from the mail server works. \\*serverip or servername *brings up the shared printers and folders perfectly. outbound traffic and icmp works fine, inbound icmp returns a time out. scenario: Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2. connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/model installed new nic drivers and proset upgraded to R2. rebooted and noticed a ton of errors with services hanging upon boot. checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled. i disabled IPSEC and entered dword value for ProhibitIpSec - nothing i then enabled ICF configured exceptions - explicitly allowing ICMP, and still nothing. reset the TCP/ip stack and winsock using netsh, nothing servers has two nics, one of which is disabled. changed binding order so active is on top -- nothing reinstalled the binaries of windows 2003 sp1 and upgraded to r2 again -- nothing. i'm at a lost of ideas and sure could use to vast resources the contributors of this group may have or know of. Thanks, -- HBooGz:\--HBooGz:\List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx -- HBooGz:\ -- HBooGz:\
Re: [ActiveDir] R2 In-Place Upgrade bug ?
The trick here is go to the bulletin and check the caveats section http://www.microsoft.com/technet/security/bulletin/MS05-019.mspx Which links to http://support.microsoft.com/kb/893066 Which points to... Network connectivity between clients and servers may not work after you install security update MS05-019. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 898060 /kb/898060/ (http://support.microsoft.com/kb/898060/) Installing security update MS05-019 or Windows Server 2003 Service Pack 1 may cause network connectivity between clients and servers to fail • For more information, click the following article number to view the article in the Microsoft Knowledge Base: 898542 /kb/898542/ (http://support.microsoft.com/kb/898542/) Windows Server 2003 systems using IPsec tunnel-mode functionality may experience problems after you install the original version of 893066 HBooGz wrote: I applied the related to article ending with MS06-007.mspx http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . do you happen to have the hotfix for the other article ? On 7/29/06, *Kurt Falde* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I would definitely get the tcpip.sys hotfixes applied as this sounds very symptomatic of ms05-019 issues. Kurt Falde Sent from my Windows Mobile Phone -Original Message- From: HBooGz[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: 7/29/06 10:58:58 AM To: ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.orgActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] R2 In-Place Upgrade bug ? I applied no post sp-1 fixes, but i would imagine it's worth a try. do you guys want to hear something even more mind-boggling ? i can ping the server from workstations outside the main office!!! i've remotely connected to workstations at our IPSEC vpns to test login times and email access,a nd pinged the problematic server just fine!!! arghhh Matheesha: Incoming connections i mean services that somehow are not defined to the server. I run a repadmin /replsum from another dc and it shows no errors. i run a dcdiag /s:problemserver with no problem. so it means that directory service traffic is allowed, but when i try to Dameware ( tcp port 6129) to the machine it times out, when i try to the ping the box i get nothing from the main office! i checked the IPSEC domain and Standard profile and made sure no IPSEC polocies were applied. if it's the SCW -- how do i look at it ? could it someway be my checkpoint firewall at the local site ? how in the world can it accept icmp from other workstations ( win2k pro) at my remote vpn sites ? On 7/29/06, Kurt Falde [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . *Kurt Falde* -- *From:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] *On Behalf Of *HBooGz *Sent:* Saturday, July 29, 2006 5:39 AM *To:* ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org *Subject:* [ActiveDir] R2 In-Place Upgrade bug ? Morning to all - I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence: The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g. telnet *server ip* 389 from the mail server works. \\*serverip or servername *brings up the shared printers and folders perfectly. outbound traffic and icmp works fine, inbound icmp returns a time out. scenario: Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2. connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/model installed new nic drivers and proset upgraded to R2. rebooted and noticed a ton of errors with services hanging upon boot. checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled. i disabled IPSEC and entered dword value for ProhibitIpSec - nothing i then enabled ICF configured exceptions - explicitly
Re: [ActiveDir] R2 In-Place Upgrade bug ?
Thank you.So it looks like i should get the hotfix related to this article:http://support.microsoft.com/kb/898060 but it says in that article that the download supplied is superceeded by the hotfix i applied already : Security update 913446 (security bulletin MS06-007) supersedes this update (898060). so which hotfixes do i really need ?what's the mystery is why can the clients and servers outside the subnet connecting via VPN ping this server by name and IP succesfully. On 7/29/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote: The trick here is go to the bulletin and check the caveats sectionhttp://www.microsoft.com/technet/security/bulletin/MS05-019.mspx Which links tohttp://support.microsoft.com/kb/893066Which points to...Network connectivity between clients and servers may not work after you install security update MS05-019. For more information, click thefollowing article number to view the article in the Microsoft KnowledgeBase:898060 /kb/898060/ ( http://support.microsoft.com/kb/898060/)Installing security update MS05-019 or Windows Server 2003 Service Pack1 may cause network connectivity between clients and servers to fail• For more information, click the following article number to view the article in the Microsoft Knowledge Base:898542 /kb/898542/ (http://support.microsoft.com/kb/898542/) WindowsServer 2003 systems using IPsec tunnel-mode functionality may experience problems after you install the original version of 893066HBooGz wrote: I applied the related to article ending with MS06-007.mspx http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . do you happen to have the hotfix for the other article ? On 7/29/06, *Kurt Falde* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I would definitely get the tcpip.sys hotfixes applied as this sounds very symptomatic of ms05-019 issues. Kurt Falde Sent from my Windows Mobile Phone -Original Message- From: HBooGz[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: 7/29/06 10:58:58 AM To: ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.orgActiveDir@mail.activedir.org mailto: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] R2 In-Place Upgrade bug ? I applied no post sp-1 fixes, but i would imagine it's worth a try. do you guys want to hear something even more mind-boggling ? i can ping the server from workstations outside the main office!!! i've remotely connected to workstations at our IPSEC vpns to test login times and email access,a nd pinged the problematic server just fine!!! arghhh Matheesha: Incoming connections i mean services that somehow are not defined to the server. I run a repadmin /replsum from another dc and it shows no errors. i run a dcdiag /s:problemserver with no problem. so it means that directory service traffic is allowed, but when i try to Dameware ( tcp port 6129) to the machine it times out, when i try to the ping the box i get nothing from the main office! i checked the IPSEC domain and Standard profile and made sure no IPSEC polocies were applied. if it's the SCW -- how do i look at it ? could it someway be my checkpoint firewall at the local site ? how in the world can it accept icmp from other workstations ( win2k pro) at my remote vpn sites ? On 7/29/06, Kurt Falde [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . *Kurt Falde* -- *From:* [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] mailto: [EMAIL PROTECTED]] *On Behalf Of *HBooGz *Sent:* Saturday, July 29, 2006 5:39 AM *To:* ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org *Subject:* [ActiveDir] R2 In-Place Upgrade bug ? Morning to all - I just spent the last 6 hours with dell gold software support team trying to figure out the following occurrence: The upgraded R2 DC does not accept incoming connections, but it appears it accepts certain connections. Particularly those related to directory services. e.g . telnet *server ip* 389 from the mail server works. \\*serverip or servername *brings up the shared printers and folders perfectly. outbound traffic and icmp works fine, inbound icmp returns a time out. scenario: Windows 2000 SP4 DC in-place upgrade to windows 2003 SP1 then upgrade to R2. connections to and from box were fine on 2003 sp1. downgraded NIC drivers to match other r2 DC on identical server hardware/model installed new nic drivers and proset upgraded to R2. rebooted and noticed a ton of errors with services hanging upon boot. checked connection to the box from workstations and servers, but all requests timed out. i made sure ICF was disabled. i
Re: [ActiveDir] R2 In-Place Upgrade bug ?
I think you are right.. I remember now they sucked in that fix to a later security bulletin. HBooGz wrote: Thank you. So it looks like i should get the hotfix related to this article: http://support.microsoft.com/kb/898060 but it says in that article that the download supplied is superceeded by the hotfix i applied already : Security update 913446 (security bulletin MS06-007) supersedes this update (898060). so which hotfixes do i really need ? what's the mystery is why can the clients and servers outside the subnet connecting via VPN ping this server by name and IP succesfully. On 7/29/06, *Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The trick here is go to the bulletin and check the caveats section http://www.microsoft.com/technet/security/bulletin/MS05-019.mspx Which links to http://support.microsoft.com/kb/893066 Which points to... Network connectivity between clients and servers may not work after you install security update MS05-019. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 898060 /kb/898060/ ( http://support.microsoft.com/kb/898060/) Installing security update MS05-019 or Windows Server 2003 Service Pack 1 may cause network connectivity between clients and servers to fail • For more information, click the following article number to view the article in the Microsoft Knowledge Base: 898542 /kb/898542/ (http://support.microsoft.com/kb/898542/) Windows Server 2003 systems using IPsec tunnel-mode functionality may experience problems after you install the original version of 893066 HBooGz wrote: I applied the related to article ending with MS06-007.mspx http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . do you happen to have the hotfix for the other article ? On 7/29/06, *Kurt Falde* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I would definitely get the tcpip.sys hotfixes applied as this sounds very symptomatic of ms05-019 issues. Kurt Falde Sent from my Windows Mobile Phone -Original Message- From: HBooGz[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: 7/29/06 10:58:58 AM To: ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.orgActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org mailto: ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] R2 In-Place Upgrade bug ? I applied no post sp-1 fixes, but i would imagine it's worth a try. do you guys want to hear something even more mind-boggling ? i can ping the server from workstations outside the main office!!! i've remotely connected to workstations at our IPSEC vpns to test login times and email access,a nd pinged the problematic server just fine!!! arghhh Matheesha: Incoming connections i mean services that somehow are not defined to the server. I run a repadmin /replsum from another dc and it shows no errors. i run a dcdiag /s:problemserver with no problem. so it means that directory service traffic is allowed, but when i try to Dameware ( tcp port 6129) to the machine it times out, when i try to the ping the box i get nothing from the main office! i checked the IPSEC domain and Standard profile and made sure no IPSEC polocies were applied. if it's the SCW -- how do i look at it ? could it someway be my checkpoint firewall at the local site ? how in the world can it accept icmp from other workstations ( win2k pro) at my remote vpn sites ? On 7/29/06, Kurt Falde [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . *Kurt Falde* --
Re: [ActiveDir] R2 In-Place Upgrade bug ?
back to square one i presume ?On 7/29/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote:I think you are right.. I remember now they sucked in that fix to a later security bulletin.HBooGz wrote: Thank you. So it looks like i should get the hotfix related to this article: http://support.microsoft.com/kb/898060 but it says in that article that the download supplied is superceeded by the hotfix i applied already : Security update 913446 (security bulletin MS06-007) supersedes this update (898060). so which hotfixes do i really need ? what's the mystery is why can the clients and servers outside the subnet connecting via VPN ping this server by name and IP succesfully. On 7/29/06, *Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The trick here is go to the bulletin and check the caveats section http://www.microsoft.com/technet/security/bulletin/MS05-019.mspx Which links to http://support.microsoft.com/kb/893066 Which points to... Network connectivity between clients and servers may not work after you install security update MS05-019. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 898060 /kb/898060/ ( http://support.microsoft.com/kb/898060/) Installing security update MS05-019 or Windows Server 2003 Service Pack 1 may cause network connectivity between clients and servers to fail • For more information, click the following article number to view the article in the Microsoft Knowledge Base: 898542 /kb/898542/ ( http://support.microsoft.com/kb/898542/) Windows Server 2003 systems using IPsec tunnel-mode functionality may experience problems after you install the original version of 893066 HBooGz wrote: I applied the related to article ending with MS06-007.mspx http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . do you happen to have the hotfix for the other article ? On 7/29/06, *Kurt Falde* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I would definitely get the tcpip.sys hotfixes applied as this sounds very symptomatic of ms05-019 issues. Kurt Falde Sent from my Windows Mobile Phone-Original Message- From: HBooGz [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] Sent: 7/29/06 10:58:58 AM To: ActiveDir@mail.activedir.org mailto: ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org mailto: ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] R2 In-Place Upgrade bug ? I applied no post sp-1 fixes, but i would imagine it's worth a try. do you guys want to hear something even more mind-boggling ? i can ping the server from workstations outside the main office!!! i've remotely connected to workstations at our IPSEC vpns to test login times and email access,a nd pinged the problematic server just fine!!! arghhh Matheesha: Incoming connections i mean services that somehow are not defined to the server. I run a repadmin /replsum from another dc and it shows no errors. i run a dcdiag /s:problemserver with no problem. so it means that directory service traffic is allowed, but when i try to Dameware ( tcp port 6129) to the machine it times out, when i try to the ping the box i get nothing from the main office! i checked the IPSEC domain and Standard profile and made sure no IPSEC polocies were applied. if it's the SCW -- how do i look at it ? could it someway be my checkpoint firewall at the local site ? how in the world can it accept icmp from other workstations ( win2k pro) at my remote vpn sites ? On 7/29/06, Kurt Falde [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote:Did you apply the post SP1 security hotfixes? I know there are a couple of updates for tcpip.sys which fix issues which will cause AD repl issues from a couple times in the field. Check out http://support.microsoft.com/kb/898060 or for the latest tcpip.sys http://www.microsoft.com/technet/security/bulletin/MS06-007.mspx . *Kurt Falde* -- *From:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] *On Behalf Of *HBooGz *Sent:* Saturday, July 29, 2006 5:39 AM *To:* ActiveDir@mail.activedir.org mailto: ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org mailto: ActiveDir@mail.activedir.org *Subject:* [ActiveDir] R2 In-Place Upgrade bug ? Morning to all - I just spent the last 6 hours with dell gold software support team trying to figure out the following
Re: [ActiveDir] Read-Only Domain Controller and Server Core
I have to admit, when I first read that my initial thought was, why? My second thought was, well, why not? But in the end my first instinct won out and I again ask, why? I mean, SBS comes on an appliance (or am I confusing that with open source version?) But to dedicate a DC to an appliance AND have an SBS box seems to defeat the purpose to me. Virtualization would be a better bet to me. RODC on Server Core would be the type of thing that could easily end up in appliance format. Heck, that's half the time spent - figuring out hardware to meet the demands. One shortcoming is that an appliance is harder to support in this scenario because the settings, performance, etc are all tied to the greater fabric. Could be a bit of a support nightmare I'm sure. To create an appliance with SBS on it would be of interest. To create one for a DC doesn't hold a lot of appeal over virtualization to me. Am I just missing something Susan? On 7/29/06, Brian Desmond [EMAIL PROTECTED] wrote: IMHO it would be hard to ship an appliance for an application whichrequires designing the hardware around the scenario... 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: Saturday, July 29, 2006 2:50 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core Ah see but I don't like mushrooms. Stupid question alert? What's the specs on this? We've always joked that in SBSland with our everything including the kitchen sink on our DCs if there was a way to make the DC services like on a linksys sized box that attached to the file/printer/email/kitchen sink box that would remove a lot of OHMYGOSHYOUDOWHATTOYOURDC! that we get from the enterprise crowd. Are there any embedded OS like plans for this server core RODC? Crawford, Scott wrote: 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 clearthe 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 don't know your enterprise or your threat model. As such, there's really no good choicewe too would be implicitly turningthe 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 I'll disagree with, there are some enterprises that will do this, but that's not the point), it is still the right state inwhich 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 *AlMulnick *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 thetraffic and rethink the view on the RODC concept. Like you said, it mayprove 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] mailto: [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, kinda...you need to more carefully define the operation. I suspectyou 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 clientsthen 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 replicationwas not allowed? There is a policy (not group policy, administrative one defined inAD 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 tobe
Re: [ActiveDir] Read-Only Domain Controller and Server Core
SBS doesn't come on an appliance remember SBS is now Windows Exchange Sharepoint ISA (yes we have our firewall on it) Also running DHCP/DNS/AD Kitchen Sink And in the R2 era WSUS SQL server 2k5 workgroup But it's not on an appliance... sucky hardware at times yes, but not appliance. But virtualization is prob the better way to go... I'm just thinking also the Centro OS that will be splitting off roles but keeping the wizardish stuff. I think you are thinking of Nitix which has an appliance version. Al Mulnick wrote: I have to admit, when I first read that my initial thought was, why? My second thought was, well, why not? But in the end my first instinct won out and I again ask, why? I mean, SBS comes on an appliance (or am I confusing that with open source version?) But to dedicate a DC to an appliance AND have an SBS box seems to defeat the purpose to me. Virtualization would be a better bet to me. RODC on Server Core would be the type of thing that could easily end up in appliance format. Heck, that's half the time spent - figuring out hardware to meet the demands. One shortcoming is that an appliance is harder to support in this scenario because the settings, performance, etc are all tied to the greater fabric. Could be a bit of a support nightmare I'm sure. To create an appliance with SBS on it would be of interest. To create one for a DC doesn't hold a lot of appeal over virtualization to me. Am I just missing something Susan? On 7/29/06, *Brian Desmond* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: IMHO it would be hard to ship an appliance for an application which requires designing the hardware around the scenario... Thanks, Brian Desmond [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] c - 312.731.3132 -Original Message- From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:ActiveDir- mailto:ActiveDir- [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Saturday, July 29, 2006 2:50 PM To: ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core Ah see but I don't like mushrooms. Stupid question alert? What's the specs on this? We've always joked that in SBSland with our everything including the kitchen sink on our DCs if there was a way to make the DC services like on a linksys sized box that attached to the file/printer/email/kitchen sink box that would remove a lot of OHMYGOSHYOUDOWHATTOYOURDC! that we get from the enterprise crowd. Are there any embedded OS like plans for this server core RODC? Crawford, Scott wrote: Well, since you offeredI'll take a large pan pepperoni and mushroom. - - -- *From:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] on behalf of Eric Fleischman *Sent:* Sat 7/29/2006 11:22 AM *To:* ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core I want to make one other thing clearthe 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 don't know your enterprise or your threat model. As such, there's really no good choicewe 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 I'll disagree with, there are some enterprises that will do this, but that's 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] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] *On Behalf Of *Al Mulnick *Sent:* Friday, July 28, 2006 3:28 PM *To:* ActiveDir@mail.activedir.org mailto: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.
RE: [ActiveDir] Read-Only Domain Controller and Server Core
Now, that would be just a little to frustrating for me :) From: [EMAIL PROTECTED] on behalf of Grillenmeier, Guido Sent: Sat 7/29/2006 3:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core Only if your sister's 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 clearthe 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 don't know your enterprise or your threat model. As such, there's really no good choicewe 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 I'll disagree with, there are some enterprises that will do this, but that's 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, kinda...you 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 clientsthen 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 knobsyou 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
Re: [ActiveDir] Read-Only Domain Controller and Server Core
I was. (but typically I'm thinking SBSized) Brian Desmond wrote: *I wasn’t thinking of SBS. SBS could totally be an appliance. I thought she meant AD in general. * * * *Thanks,* *Brian Desmond* [EMAIL PROTECTED] * * *c - 312.731.3132* * * *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Al Mulnick *Sent:* Saturday, July 29, 2006 9:48 PM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] Read-Only Domain Controller and Server Core I have to admit, when I first read that my initial thought was, why? My second thought was, well, why not? But in the end my first instinct won out and I again ask, why? I mean, SBS comes on an appliance (or am I confusing that with open source version?) But to dedicate a DC to an appliance AND have an SBS box seems to defeat the purpose to me. Virtualization would be a better bet to me. RODC on Server Core would be the type of thing that could easily end up in appliance format. Heck, that's half the time spent - figuring out hardware to meet the demands. One shortcoming is that an appliance is harder to support in this scenario because the settings, performance, etc are all tied to the greater fabric. Could be a bit of a support nightmare I'm sure. To create an appliance with SBS on it would be of interest. To create one for a DC doesn't hold a lot of appeal over virtualization to me. Am I just missing something Susan? On 7/29/06, *Brian Desmond* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: IMHO it would be hard to ship an appliance for an application which requires designing the hardware around the scenario... Thanks, Brian Desmond [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] c - 312.731.3132 -Original Message- From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:ActiveDir- mailto:ActiveDir- [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Saturday, July 29, 2006 2:50 PM To: ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core Ah see but I don't like mushrooms. Stupid question alert? What's the specs on this? We've always joked that in SBSland with our everything including the kitchen sink on our DCs if there was a way to make the DC services like on a linksys sized box that attached to the file/printer/email/kitchen sink box that would remove a lot of OHMYGOSHYOUDOWHATTOYOURDC! that we get from the enterprise crowd. Are there any embedded OS like plans for this server core RODC? Crawford, Scott wrote: Well, since you offeredI'll take a large pan pepperoni and mushroom. - - -- *From:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] on behalf of Eric Fleischman *Sent:* Sat 7/29/2006 11:22 AM *To:* ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core I want to make one other thing clearthe 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 don't know your enterprise or your threat model. As such, there's really no good choicewe 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 I'll disagree with, there are some enterprises that will do this, but that's 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] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] *On Behalf Of *Al Mulnick *Sent:* Friday, July 28, 2006 3:28 PM *To:* ActiveDir@mail.activedir.org mailto: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] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[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
