Re: [ActiveDir] [OT] Can I add an index in AD using an LDIF file?
I hear Bill and Melinda are very charitable. Not sure if they'd wanna adopt a 6 foot 1 uber geek though. ;-)M@On 7/29/06, joe
[EMAIL PROTECTED] wrote:
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.
[ActiveDir] DNS oddities?
AllCan someone please explain the following observation?Installed a new R2 DC forest with one DC/DNS.created a new dns zone for use by a child domain (yet to be created). The zone is replicated to all domain controllers of the root domain. Enabled secure dynamic update only. Installed a new child domain and pointed to root domain DC/DNS. All records required were created apart from the A record for the child DC. How come it can create all records other than the A record?. If I delete the child donain's zone from the parent domain DC/DNS server, and recreate it, then use netdiag /test:dns /fix on the child DC. It does the same. Creates all records except for the A. I am puzzled as if the secure dynamic updates allow all these records to be created, whats up with the A record?Also netdiag /test:dns on child DC reports all required everything as OK even though the A record is missing in the child domain zone. Thoughts?CheersM~
RE: [ActiveDir] DNS oddities?
I bugged the behavior many moons ago … to my knowledge, no fix has appeared as yet. The precise cause escapes me but IIR it was related to the ticket/token attached to the DHCP client service on the newly-born domain’s DC. Two immediate solutions exist - 1. reboot the new DC one more time 2. or - a. temporarily configure the zone to permit non-secure updates b. on the new DC, run ipconfig /registerdns or restart the DHCP client HTH -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Sunday, July 30, 2006 3:07 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] DNS oddities? All Can someone please explain the following observation? Installed a new R2 DC forest with one DC/DNS. created a new dns zone for use by a child domain (yet to be created). The zone is replicated to all domain controllers of the root domain. Enabled secure dynamic update only. Installed a new child domain and pointed to root domain DC/DNS. All records required were created apart from the A record for the child DC. How come it can create all records other than the A record?. If I delete the child donain's zone from the parent domain DC/DNS server, and recreate it, then use netdiag /test:dns /fix on the child DC. It does the same. Creates all records except for the A. I am puzzled as if the secure dynamic updates allow all these records to be created, whats up with the A record? Also netdiag /test:dns on child DC reports all required everything as OK even though the A record is missing in the child domain zone. Thoughts? Cheers M~
[ActiveDir] DNS suffix resolution..
I have a Forrest with one forest root and one child domain.The child domain is running windows 2000 SP4 and the HQ sites are running windows 2003 R2 standard.I have the the child domain controller setup as an AD-integrated zone and i have the 2003 DNS servers setup to receive that zone as a secondary zone. if i don't include the suffix search order on the nic cards' dns entry page, i just resolve the netbios names of the hosts at the remote site. for example.hq = company.com child domain = sales.company.comwhen i initiate a ping from any host at HQ to a host in the child domain i only resolve the netbios name. how can i resolve this ? I've tried setting up dns name delegation in the past when i was running a full 2000 domain, but that name resolution never worked right and it wasn't timely.thanks,-- HBooGz:\
RE: [ActiveDir] Read-Only Domain Controller and Server Core
RE: RODC PAS
Oi, that will add some nice complexity to all of
this... :)
If I was looking to implement that I think I would look
at doing it in four levels so people don't shoot themselves... Everything,
everything but password info, core NOS info required for auth/authz
withpasswords, core NOS w/o passwords.
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dmitri
GavrilovSent: Friday, July 28, 2006 12:48 PMTo:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain
Controller and Server Core
The
set of passwords that *can* be sent down to the RODC is controlled by
password replication policy. The passwords are sent down by RODCs request, but
the hub also checks whether the user (whose pwd is being requested) actually
attempted to authenticate at RODC (the hub can induce this info from the traffic
is sees). The pwd hash is sent down only if both are satisfied: pwd policy
allows it and the user actually attempted to logon there.
Pwd
policy is empty by default, i.e. nobody is in allowed to reveal list. It is
admins responsibility to populate this list. We might have some UI that helps
with this process.
Once
the hash is sent down, theres no way to remove it from RODC, basically because
we do not trust that RODC will remove it, even if instructed to do so.
Therefore, the only way to expire the hash is to change the password. We store
the list of passwords that were sent down to RODC in an attribute on the RODC
computer object (the hub DC updates the list when it sends a pwd). So, if the
RODC is stolen, you can enumerate whose passwords were down there, and make
these users reset their passwords. Theres a constructed attribute that returns
only the users whose *current* passwords appear to be on the
RODC.
WRT
what data is sent down currently, we send everything, sans a handful of
secret attributes, which are controlled by pwd replication policy. Theres a
DCR to be able to configure the list of attributes that can go down to RODC (aka
RODC PAS), but it is not yet clear if we will get it done or not. Note
that the client data access story on RODC becomes quite convoluted because you
dont know if you are seeing the whole object or only a subset of it. We do not
normally issue referrals due to partial reads.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of [EMAIL PROTECTED]Sent: Friday, July 28,
2006 8:22 AMTo: ActiveDir@mail.activedir.orgSubject: RE:
[ActiveDir] Read-Only Domain Controller and Server
Core
RODC
stores password hashes only for a pre defined list of users and they are not
stored on a permanent basis. [I'm unclear how the latter is
achieved.]
The goal
is such that if the RODC were removed from the office then no password secrets
could be extracted from that machine.
neil
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Al MulnickSent: 28 July 2006 16:08To:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Read-Only Domain
Controller and Server Core
The part that makes me wonder about the "story" is if it
stores no secrets is the server doing anything for me?Is there a point to
deploying the server in a remote office other than just being able to point to
it in the closet and say, "see, I do toearn my paycheck!"
I'm sure there's more, but I don't yet know which parts are
public information and which are NDA.
Can you tell I'm concerned about the story being created? I
like stories; don't get me wrong. But I'm concerned that the story being
spun up might be missing the mark and lead a few people astray.
Safe to note that there are some features that differentiate
the RODC from a NT4 BDC and that make it appealing in some
cases.
But if it actually does not store anything locally, ever,
then I'm not sure it's worth the time to deploy one now is it?
Al
On 7/27/06, Susan Bradley, CPA aka
Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote:
FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only
Domain Controller and Server CoreList info : http://www.activedir.org/List.aspxList
FAQ: http://www.activedir.org/ListFAQ.aspxList
archive: http://www.activedir.org/ml/threads.aspx
PLEASE READ: The
information contained in this email is confidential and
intended for the
named recipient(s) only. If you are not an intended
recipient of this
email please notify the sender immediately and delete your
copy from your
system. You must not copy, distribute or take any further
action in reliance on
it. Email is not a secure method of communication and
Nomura International
plc ('NIplc') will not, to the extent permitted by law,
accept responsibility
or liability for (a) the accuracy or completeness of,
or (b) the presence
of any virus, worm or similar malicious or disabling
code in, this message
or any attachment(s) to
Re: [ActiveDir] R2 In-Place Upgrade bug ?
anywhere i can possibly look ?i'm running out of options and i have a long week ahead with microsoft PSS and Dell.On 7/29/06, HBooGz [EMAIL PROTECTED] wrote: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
Re: [ActiveDir] Read-Only Domain Controller and Server Core
Um, why? What value at this point? Last I checked it supports limited applications that might want that information. And if you follow ~Eric's logic, they want to be secure out of the box. That would indicate that they want it to be as minimal as possible until and unless told otherwise. To put that information in there by default might be counter to that. Now, if you had some templates or something so that we didn't have to work on the carpal tunnel, that would be something:) On 7/30/06, joe [EMAIL PROTECTED] wrote: RE: RODC PAS Oi, that will add some nice complexity to all of this... :) If I was looking to implement that I think I would look at doing it in four levels so people don't shoot themselves... Everything, everything but password info, core NOS info required for auth/authz withpasswords, core NOS w/o passwords. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dmitri GavrilovSent: Friday, July 28, 2006 12:48 PM To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core The set of passwords that *can* be sent down to the RODC is controlled by password replication policy. The passwords are sent down by RODC's request, but the hub also checks whether the user (whose pwd is being requested) actually attempted to authenticate at RODC (the hub can induce this info from the traffic is sees). The pwd hash is sent down only if both are satisfied: pwd policy allows it and the user actually attempted to logon there. Pwd policy is "empty" by default, i.e. nobody is in "allowed to reveal" list. It is admin's responsibility to populate this list. We might have some UI that helps with this process. Once the hash is sent down, there's no way to remove it from RODC, basically because we do not trust that RODC will remove it, even if instructed to do so. Therefore, the only way to "expire" the hash is to change the password. We store the list of passwords that were sent down to RODC in an attribute on the RODC computer object (the hub DC updates the list when it sends a pwd). So, if the RODC is stolen, you can enumerate whose passwords were down there, and make these users reset their passwords. There's a constructed attribute that returns only the users whose * current* passwords appear to be on the RODC. WRT what data is sent down – currently, we send everything, sans a handful of "secret" attributes, which are controlled by pwd replication policy. There's a DCR to be able to configure the list of attributes that can go down to RODC (aka RODC PAS), but it is not yet clear if we will get it done or not. Note that the client data access story on RODC becomes quite convoluted because you don't know if you are seeing the whole object or only a subset of it. We do not normally issue referrals due to "partial reads". From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED]Sent: Friday, July 28, 2006 8:22 AMTo: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core RODC stores password hashes only for a pre defined list of users and they are not stored on a permanent basis. [I'm unclear how the latter is achieved.] The goal is such that if the RODC were removed from the office then no password secrets could be extracted from that machine. neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al MulnickSent: 28 July 2006 16:08To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Read-Only Domain Controller and Server Core The part that makes me wonder about the story is if it stores no secrets is the server doing anything for me?Is there a point to deploying the server in a remote office other than just being able to point to it in the closet and say, see, I do toearn my paycheck! I'm sure there's more, but I don't yet know which parts are public information and which are NDA. Can you tell I'm concerned about the story being created? I like stories; don't get me wrong. But I'm concerned that the story being spun up might be missing the mark and lead a few people astray. Safe to note that there are some features that differentiate the RODC from a NT4 BDC and that make it appealing in some cases. But if it actually does not store anything locally, ever, then I'm not sure it's worth the time to deploy one now is it? Al On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote: FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx Read-Only Domain Controller and Server CoreList info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this
RE: [ActiveDir] Read-Only Domain Controller and Server Core
I agree 100%, secure by default, make the admins learn how to make it less secure. This has been one of the core security issues Microsoft has had forever. It is good that this has turned around and while it pisses off the lesser quality admins, it is good for Windows and the computing communityas a whole. If your admins need their hands held, you need new admins. Get your checkbook out and stop being stingy. :) I'll take ham,pepperoni,capsicum, black olives, onions, mushrooms, extra sauce, and garlic butter crust please. :) -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric FleischmanSent: Saturday, July 29, 2006 12:23 PMTo: 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
RE: [ActiveDir] Read-Only Domain Controller and Server Core
Apologies as Im reading in digest. But I just wanted to chip something into this surrounding OUs versus groups as it was something that Ive been thinking about on my mind-numbing commute. I understood that RODCs could be configured to be a read only subset of objects (users) from the writeable AD, or that you could set them to cache which would also be useful to catch user population at a given site if this was unknown. I remember there being a long discussion at the back of DEC about people wanting the subset replication to be based around OUs rather than groups, and lots of people being quite passionate about it. The thing that struck me was how would you then deal with group membership where the group was sat in a totally different part of the tree? Somehow youve got to get that closed set to work with, which is very loosely linked to migration strategies. (Blimey I must have paid attention on that migration course all of those years ago.). And then youve got constraints on OU structures for if they are now partitions for replication in some capacity. How wrong is this understanding? If its kind of right, then at some point in the future are we going to see multiple domain partitions hosted on DCs? Cos that would be nice as well as the ability to replicate subsets as read only. Where a GC could hold writeable copies of domain partitions that werent from its particular domain in the forest.. etc mmm DC consolidation, the possibilities! Then going more OT. There were also rumblings about ROGCs so that didnt contain sensitive info and could be used purely for email purposes without the baggage of a full fat DC. Is this correct and how does this relate to Exchange 2007 and its Edge servers, which from what I can gather are looking to suck bits of the AD into an ADAM for kind of the same purpose as an ROGC would perform? I may be totally babbling now. RE: [ActiveDir] Read-Only Domain Controller and Server Core From: Grillenmeier, Guido [EMAIL PROTECTED] Date: Sat, 29 Jul 2006 17:14:51 +0100 Al, thats basically getting back at what Eric said and the more I think about it, the more I have to agree: there is only a certain percentage of companies that are able to setup an OU structure by geography and certainly no single OU structure will fit for all companies. I have myself worked with quite a lot of customers, where OUs by location made sense but also some that had a mix of location-OUs for computers and business units-OUs for users. And others simply adjust it to their helpdesk model depending on who needs to manage which part of the world. Thinking more about the travel bit, it will be easy to understand that this doesnt make the password caching story any easier. If you want full coverage for WAN outages (which is the main reason that you want to cache the passwords in the first place), then you may need to match those traveling users (and computers) to multiple sites this is where the fun begins with figuring out how to handle the password replication policies for RODCs. Granted, OUs suddenly make less sense, since a user and a computer can only be in a single OU, but they can belong to multiple groups
RE: [ActiveDir] R2 In-Place Upgrade bug ?
Is this on a separate network segment then your other boxes that youre utilizing to ping it? If not I would say make sure you put a laptop into a switch port that you are positive is in the same vlan as this server and start doing some testing there to ping the server. Have you taken a network trace on the server side to see if you see any of these connections getting to the server however the response not getting back to the originator? Kurt Falde From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of HBooGz Sent: Sunday, July 30, 2006 6:36 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] R2 In-Place Upgrade bug ? anywhere i can possibly look ? i'm running out of options and i have a long week ahead with microsoft PSS and Dell. On 7/29/06, HBooGz [EMAIL PROTECTED] wrote: 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
RE: [ActiveDir] Read-Only Domain Controller and Server Core
I am not sure if I understand where you are going but let me explain where I am coming from. First, the passwords being there or not being there is not important for this talk, that is already built in and will be there, now the discussion is around everything versus an RODC PAS. Everything is already there as well but is an important option because it will be the most used option. Actually I expect to see a ton of RODCs deployed that are configured as replicate everything including passwords so that people get the RO part of the benefit and they don't have to worry about replicating bad stuff back into the "real directory" and not have to worry about password caching management, if someone logs on somewhere, the password is cached there, bob's your uncle have a nice day. So now we get down to replicating a portion of the normal attribute set. Why would you want to do this? Because you want to minimize the traffic to WAN sites and/or reduced info in some locations in case of compromise. For instance, if the email addresses of everyone in the company isn't on a DC in a WAN site and someone steals that DC hoping to get those email addresses, they are SOL; they missed. However, now think about this from a application developer standpoint and it is the same issue that exists with GCs only worse because it is DCs. If an app developer wants to find something, they need to understand what they can actually find in the GC in terms of what attributes are populated. Maybe they (a) put in a requirement and hope people follow it, maybe they (b) actually try to verify it, maybe they (c) say screw that and query a DC instead because they know all of the data is there for a full query. From what I have seen the likely cases for an app that can handle any query is C, A, and in the absolute blue moon case B. Usually the app will just fail to find what it needs if you specify an attribute that isn't in the GC. How does Exchange do it??? So there are hybrids like where certain things that people KNOW will always be in GC PAS and they will set it up so that queries using those things will use a GC and everything else will go to a DC. We already know that the same override that exists for the GC PAS would have to exist for an RODC PAS so why not just make that the other option and be done with it? I don't really see the majority of developers doing this any better with RODCs than they do with GCs and so it seems like a lot of make work to allow for the flexible handling of that if you just say these are the options. Again also the password thing isn't even worried about at the app level since apps can play with those anyway. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Sunday, July 30, 2006 6:57 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Read-Only Domain Controller and Server Core Um, why? What value at this point? Last I checked it supports limited applications that might want that information. And if you follow ~Eric's logic, they want to be secure out of the box. That would indicate that they want it to be as minimal as possible until and unless told otherwise. To put that information in there by default might be counter to that. Now, if you had some templates or something so that we didn't have to work on the carpal tunnel, that would be something:) On 7/30/06, joe [EMAIL PROTECTED] wrote: RE: RODC PAS Oi, that will add some nice complexity to all of this... :) If I was looking to implement that I think I would look at doing it in four levels so people don't shoot themselves... Everything, everything but password info, core NOS info required for auth/authz withpasswords, core NOS w/o passwords. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dmitri GavrilovSent: Friday, July 28, 2006 12:48 PM To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core The set of passwords that *can* be sent down to the RODC is controlled by password replication policy. The passwords are sent down by RODC's request, but the hub also checks whether the user (whose pwd is being requested) actually attempted to authenticate at RODC (the hub can induce this info from the traffic is sees). The pwd hash is sent down only if both are satisfied: pwd policy allows it and the user actually attempted to logon there. Pwd policy is "empty" by default, i.e. nobody is in "allowed to reveal" list. It is admin's responsibility to populate this list. We might have some UI that helps with this process. Once the hash is sent down, there's no way to remove it from RODC, basically
RE: [ActiveDir] RE: [ActiveDir] Read-Only Domain Controller and Server Core
I think the story is the fault of the blog post writer. That wasn't someone who actually knows what is going on, that was someone who say an internal pres that was put on by a PM, probably Nathan, of what they are thinking right now and the writer tried to get across the points as he/she understood them because he/she thought it was (and it really is) cool. I wouldn't take that blog entry to be authoritative for anything on the topic. Heck it was even stated that "These features in-turn reduce the attack surface of a Windows Server." and it absolutely does nothing to reduce the attack surface of a Windows Server, it helps reduce the attack surface on AD as a service. 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 1:23 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] RE: [ActiveDir] Read-Only Domain Controller and Server Core To be completely fair, I'mNOTthe one that said that it doesn't store anything. I questioned that from the bloglink that was posted, because I know that itcan/does store some information which would make it useful.Not that you can get anything from that information, but then again, it's early in the adoption cycle (just before it really) so there hasn't been a large enough crowd to hammer away at it. Being highly familiar with BO environments, I agree it opens plenty of opportunity to deploy more DC's where before we could not. In some industries, that is far more important than others, but useful nonetheless. Note that my original concern was the way that the blog post mentioned the product and that it might be a deviation from the original story when the RODC concept was created and brought to life. I have seen the RODC before, but I am far more limited with what I can talk about and can't. Since I don't know what those limits are, I'm erring on the side of not even coming close to mentioning what I do and don't know nor some of the other questions that come to mind regarding that concept and it's boundaries. This is not the forum for that. On 7/28/06, Tim Vander Kooi [EMAIL PROTECTED] wrote: I'm not sure why you say it doesn't store anything??? It stores EVERYTHING, it simply doesn't get the rights to write anything new back to your core DCs. This is a HUGE breakthrough for those of us with smaller branch offices that today can't cost justify putting an entire server in a BO just to handle authentication, but at the same time we are not willing to open the security hole that is created if you put the DC services on a file server in those offices.. With a RODC I can deploy authentication, as well as hopefully sites, etc. to those file servers without concern that a user might hack in and take over my AD. The number of doors this opens to a spread server architecture is really big. Granted, if you have no branch offices it won't a thing to you. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Friday, July 28, 2006 10:08 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core The part that makes me wonder about the "story" is if it stores no secrets is the server doing anything for me?Is there a point to deploying the server in a remote office other than just being able to point to it in the closet and say, "see, I do toearn my paycheck!" I'm sure there's more, but I don't yet know which parts are public information and which are NDA. Can you tell I'm concerned about the story being created? I like stories; don't get me wrong. But I'm concerned that the story being spun up might be missing the mark and lead a few people astray. Safe to note that there are some features that differentiate the RODC from a NT4 BDC and that make it appealing in some cases. But if it actually does not store anything locally, ever, then I'm not sure it's worth the time to deploy one now is it? Al On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote: FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx Read-Only Domain Controller and Server CoreList info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
RE: [ActiveDir] ldp in ADAM-SP1
Hi Al, I’m going to have to disagree here. I’d wager that the average programmer has a better understanding of writing code that has: a) proper specifications and design b) robust error handling c) strong typing d) etc Of course, there are always deadlines that result in shoddy code, and there are certainly some shoddy programmers. But the average scripter (in my experience) seems to have far fewer clues on how to write robust, reusable, defensive code than the average programmer. The average scripter doesn’t know much about IDEs, debugging, source control, unit tests and all the other goodies that make maintaining large bodies of code easy. There’s nothing wrong with writing scripts – especially for things that just require a few lines of code. Trying to maintain something that has 1000+ lines of code is a nightmare when scripted using VBS/JScript Cheers Ken From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Sunday, 30 July 2006 10:17 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 I have to say that's weak logic joe. Well, good logic, but weak assumptions. Tool writers are no more likely to prevent unforseen mistakes than a script writer. On the plus side, if you write your own script, you'll have plenty of time to test it and will have gained a great deal more knowledge than you previously had. Mostly about how not to do it, but that's better than figuring that out in production or worse, trusting the tool writer to have done the work for you and to have guessed what you wanted done. joeware tools excepted in most cases of course ;) On 7/29/06, joe [EMAIL PROTECTED] wrote: 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
[ActiveDir] bulk user creation
Title: Message Hello All, I have a round 350 users to be created with their mailboxes in windows 2003, what is the best way to automate the process or delegate this job to two account operators. Any suggestions are highly recommended. Regards, DISCLAIMER: This electronic message transmission contains information from Qatar Steel Company (QASCO) which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. Be aware that any disclosure,copying, distribution or use of the contents of this information,including attachments, is prohibited without the written consent of Qatar Steel Company (QASCO).
