[ActiveDir] Sudhir Kaushal/GIS/CSC is out of the office.
I will be out of the office starting 09/18/2006 and will not return until 09/25/2006. I will respond to your message when I return. 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] VBScript Container Security
Try starting with this document...one ohe preferred methods is to create the System container and manally assign permissions to it... http://www.microsoft.com/technet/prodtechnol/sms/smssp2/spsecurity/3df7a6e2-e173-4def-a81a-5bd90fbbf9d8.mspx?mfr=true Matt Duguid Systems Engineer for Identity Services Department of Internal Affairs Phone: +64 4 4748028 (wellington) Mobile: +64 21 1713290 Fax: +64 4 4748894 Address: Level 4, 47 Boulcott Street, Wellington CBD E-mail: [EMAIL PROTECTED] Web: http://www.dia.govt.nz/ |-+--> | | | | | | | | | | | "Joe McNicholas" | | | <[EMAIL PROTECTED]>| | | Sent by: | | | [EMAIL PROTECTED]| | | tivedir.org| | | | | | | | | 15/09/2006 09:53 p.m. | | | Please respond to | | | ActiveDir | | | | |-+--> >--| | | |To: | |cc: | |Subject: [ActiveDir] VBScript Container Security | >--| I'm trying to create and secure the "LDAP://cn=System Management,cn=System,dc=mydomain,dc=com" container, as required for SMS[1]. I'm able to create the container successfully, but haven't found any examples of how to assign security to an OU or Container in the AD. MS Script Centre and a quick google have come up blank, can anyone point me to any examples? Thanks Joe [1] Ref: https://www.microsoft.com/technet/prodtechnol/sms/smssp2/spsecurity/3df7a6e2-e173-4def-a81a-5bd90fbbf9d8.mspx?mfr=true 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] Slightly OT: Modifying AD vbscript
Couple of other things to point out in the code:
If you're going to use a counter, be sure to set it to some known value (usually 0). That's just a neatness item, but it helps.
When you search with that method (enumerate) then you're trying to enumerate every user in the domain and return those with the value of blue bell in the description field that are users. When you meet up with an OU, then re-enter the function. You are passing two variables to the function that only accepts one however. I suspect you'll want to fix that.
I also don't think you're taking into account the proper types. You took into account what to do if you ran into an OU, but not a CN. Why not?
Finally, if it were me, I'd use a different method. Using that enumeration works fine if you have plenty of time to wait and if you know the OU/CN you want to query in the first place. If you don't, I think you'd do better with adsi type calls instead.
My $0.04 worth (USD)
On 9/15/06, joe <[EMAIL PROTECTED]> wrote:
However this isn't a query, it is an enumeratiion, no 1000 record limit here...
There could be various issues. I don't code in _vbscript_ enough to catch issues at a glance especially with recursive functions which can introduce nice oddities. The OP doesn't indicate the number of users he considers "too high" but if there were a rollover going on, it would be quite odd if the count actually resulted in zero versus some other positive or negative number which you normally get with integer overflow.
My recommendation would be to add in what are called debug or trace statements which simply output status generously that tell you the count every time it is updated as well as info about when a new OU is being opened up. More than likely, you will see the code dumping out at some point.
Writing this as an ADO query would be substantially faster over enumeration and recursion.
And if you are curious... :o)
adfind -default -f "&(samaccounttype=805306368)(description=Blue Bell)" -c
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, September 15, 2006 4:13 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Slightly OT: Modifying AD _vbscript_
You are almost assuredly running into the default return limit of 1000 items. AD queries will only return that many items per query by default. In order to retrieve more information you need to use paging. I personally use SQL style syntax because I know SQL and that is what the MS script center has available for learning. Therefore the relevant code for me is
objCommand.Properties("Page Size") = 1000, I am unsure how you would modify your query to use paging, perhaps someone else can chime in with the syntax needed. Thanks,
Andrew Fidel
"Alex Alborzfard" <[EMAIL PROTECTED]
> Sent by: [EMAIL PROTECTED]
09/15/2006 12:28 PM
Please respond toActiveDir@mail.activedir.org
To
cc
Subject
[ActiveDir] Slightly OT: Modifying AD _vbscript_
I'm sure this can be done more elegantly with joeware's tools or others, but in the spirit of learning, I whipped up this primer _vbscript_ with the help from a site.
What I want to do is to modify it, so it can count # of employees in each location and output it to a simple text/csv file.
In our AD, we enter the location name in the Description field. Also when the number is too high, the script doesn't return anything. I think I have to change the variable type of intCounter to something that can hold bigger values,
but don't know what. Can some one take a look and help me or give me pointers?
TIA Alex
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED]] On Behalf Of Alex AlborzfardSent: Wednesday, September 13, 2006 9:22 AM
To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OT: Management Solutions
What is the largest environment WSUS can be deployed effectively? At what point you're better off going with something like Shavlik or Patchlink?
What do they give you that WSUS doesn't? We're trying to put in place a patch management solution for a company that's midsize (~1700 users), but with offices scattered all over the world.
But we're not sure how to architect the whole thing (how many servers, layers, and where-what's the cutoff point:bandwidth, # of users?-).
The other issue is the industry we're in: healthcare. We're constantly audited and for every single task we have to test, write validation and justification.
So we're not sure how can we do this, with so many patches MS puts out every Tuesday, without going insane! And this is just for desktops; servers are
a whole different ball of wax. Anybody out there had to deal with similar issues?
Alex
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED]] On Behalf Of Brian DesmondSent: Monday, September 11, 2006 9:34 PM
To: ActiveD
RE: [ActiveDir] Elevating privileges from DA to EA
Oh expect that. Locking down rarely, or at least rarely in my experience, is from really bad to really good. You seem to go through levels as people see the benefit and realize that people can still do their work. You lock down to some level, everyone gets used to it, you find more things that can be locked down and you get buyin so you do it, rinse, lather, repeat -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul WilliamsSent: Sunday, September 17, 2006 10:18 AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Elevating privileges from DA to EA Lucky you : ) I'm in an environment where we're doing this now, and I'm not happy with how its being done (I think we can be even more secure ;-), which means I've accidently volunteered to re-look at it all for the next iteration of the design cycle... (bollocks) --Paul - Original Message - From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Friday, September 15, 2006 5:22 PM Subject: RE: [ActiveDir] Elevating privileges from DA to EA Thanks Paul., Joe's been there and done it... LOL - so have I several time before :) neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul WilliamsSent: 15 September 2006 09:46To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Elevating privileges from DA to EA Neil, Try a re-read of the first couple of chapters of the first part of the deployment guide book designing and deploying directory and security services. Obviously it doesn't spell out how to do this -it doesn't even allude to how this is done- but does emphasise when and when not to go with the regional domain model. I'm not disputing what anyone is saying here -I agree. I just happen to think the regional model can be a good one, and that if done properly works. Even from a security stand point. The main thing with the regional design is that there's a central group of service admins, or a true delegated model. If you have multiple groups of service admins it can still work, but the issue that has been raised is very real and you probably need to implement processes and monitor against it (if you're forced into such a design by the needs of the business or obtuse upper management ;-). Although it does seem to be possible to implement disparate groups of service admins if you follow the delegation whitepaper (you'll need to improvide, but most of the info. is pertinent), which should put you in a much stronger position from a security stand point. If you can achieve a very small number of people who are actually members of the builtin\Administrators group, and the rest only have delegated permissions and privileges (and preferably very few privileges on the DCs, i.e. no logon locally) you can achieve what you want. Joe's been there and done it... --Paul - Original Message - From: Almeida Pinto, Jorge de To: ActiveDir@mail.activedir.org Sent: Friday, September 15, 2006 8:48 AM Subject: RE: [ActiveDir] Elevating privileges from DA to EA >>>Al - we are designing a forest with regional domains (don't ask!) and one region has suggested it needs to split from this forest since elevating rights in any regional domain from DA to EA (forest wide) is 'simple' [and this would break the admin / support model]. What is being said is very very true. Either you trust ALL Domain Admins (no matter the domain those are in) or you do not trust ANY! Every Domain Admin or ANY person with physical access to a DC has the possibility to turn the complete forest into crap! Because if that was NOT the case the DOMAIN would be the security boundary. Unfortunately it is not! The Forest is the security boundary, whereas EVERY single DC in the forest MUST be protected and EVERY Domain Admin MUST be trusted! >>>I am arguing that it is not simple and am looking for methods which may be used to elevate rights as per the above When you know HOW, it is as easy as taking candy from a baby jorge From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Friday, September 15, 2006 09:36To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Elevating privileges from DA to EA Thanks for responses, all. Al - we are designing a forest with regional domains (don't ask!) and one region has suggested it needs to split from this forest since elevating rights in any regional domain from DA to EA (forest wide) is 'simple' [and this would break the
RE: [ActiveDir] Elevating privileges from DA to EA
I should expose one or two of my VM environments, I could stand to lose a few pounds. :) There are things that can be done that can be reversed, there are other things that you can't get out of unless you have good working offline backups of your entire forest and your domain is gone until you recover a couple of the DCs and repromote the rest of your environment from them. As you mention, LH doesn't stop everything but it helps in certain scenarios. The primary point is that you are reducing surface area with the RODCs. You can still do some stupid things with them but that is more up to you. Theoretically, you should be able to *properly* deploy an RODC to a site and not have to fear being hacked through it. However, that remains to be seen, as previously mentioned, you cannot prove an environment secure, only insecure. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams Sent: Sunday, September 17, 2006 10:25 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Elevating privileges from DA to EA It doesn't matter what domain it is in. If you have access to it you can hack it. What you do once you've hacked it is up to you. Jorge and I just tested this and we we able to do some serious damage. It was trivial to delete domain controllers and move FSMO roles and other things, etc. And this applies to both 2000 and 2003. Longhorn's different. One of the easy attack vectors has been removed. I doubt all have, but can't test at the moment as I'm loosing the will to live waiting for applications to open and the ability to double click things (running on a VM ;-) Note. Its likely that any damage caused can be undone, as AD is very flexible in that regard. However the damage caused by someone accessing data or systems that they shouldn't is much worse, and can cause millions of pounds of loss. --Paul - Original Message - From: "Kevin Brunson" <[EMAIL PROTECTED]> To: Sent: Friday, September 15, 2006 9:41 PM Subject: RE: [ActiveDir] Elevating privileges from DA to EA > "Elevating priveledges from DA to EA (or from physical DC access to EA) > is simple" > > Is this physical access to a DC in the root domain or physical access to > a DC with a forest trust to the root domain? > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Friday, September 15, 2006 12:15 PM > To: ActiveDir@mail.activedir.org > Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] > Subject: Re: [ActiveDir] Elevating privileges from DA to EA > > Hi All > > I wanted to weigh in with two comments. > 1) Elevating priveledges from DA to EA (or from physical DC access to > EA) > is simple - it takes about 45 minutes and unless you have some very good > active monitoring is difficult to detect. There are automated tools out > there for doing this. I have been known to use the term lazy EAs to > refer > to domain admins. > > 2) Replication boundaries is another reason for separate domains. a > million objects can lead to huge DITs and very slow replication - > especially in a build a new DC case. Separating that into multiple > domains > - to put smaller load on locations where bandwidth is an issue is worth > considering. For example. > 90,000 users. 200 of those are in Alaska > The rest of the world has good bandwidth, Alaska locations all > have > the equivalent of 56K modem speed. > DIT and Sysvol size is about 7G, but for Alaska users there are > only > 3 GPOs that affect them > Rather then doing 1 domain I can put the 200 Alaska users in their > own domain. Security wise, there is no advantage. Replication wise, > the > Global Catalgue is a fraction the size of the full database, the Sysvol > never replicates anywhere in Alaska,and replicaiton for that > domain will cause less strain on their bandwidth - 200 users will create > a > much lower amount of changes then 90,000 users. > > Regards; > > James R. Day > Active Directory Core Team > Office of the Chief Information Officer > National Park Service > 202-230-2983 > [EMAIL PROTECTED] > > > > > "Al Mulnick" > > <[EMAIL PROTECTED] > > om> > To > Sent by: ActiveDir@mail.activedir.org > > [EMAIL PROTECTED] > cc > ail.activedir.org > > > Subject > Re: [ActiveDir] Elevating > > 09/15/2006 11:34 privileges from DA to EA > > AM AST > > > > > > Please respond to > > [EMAIL PROTECTED] > >tivedir.org > > > > > > > > > > I agree and add to that some additional thoughts: > Not long ago there was some conversation around a suggestion that > [EMAIL PROTECTED] put out regarding the idea of using multiple > forests > vs. do
RE: [ActiveDir] Elevating privileges from DA to EA
I think Aric was just specifically bringing it back to the original point of having some domains (say regional domains) with different DA's than others. I can assure you that Aric could hack an AD with the best of them. :o) -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams Sent: Sunday, September 17, 2006 10:28 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Elevating privileges from DA to EA DAs got nothing to do with it. It makes it easier, but this can be done by someone without any account at all. --Paul - Original Message - From: "Bernard, Aric" <[EMAIL PROTECTED]> To: ; Sent: Friday, September 15, 2006 10:33 PM Subject: RE: [ActiveDir] Elevating privileges from DA to EA > Kevin, > > FWIW - as others are stating, assuming you know what you are doing, it is > *simple* and painless so long assuming that you are a DA of any domain in > the forest and have access to the console of a GC. There are many > exploits strategies in this area and in its most basic form this can be > done with rudimentary knowledge, native tools, and no coding or scripting. > > > Aric > > -Original Message- > From: "Kevin Brunson" <[EMAIL PROTECTED]> > To: "ActiveDir@mail.activedir.org" > Sent: 9/15/06 1:35 PM > Subject: RE: [ActiveDir] Elevating privileges from DA to EA > > http://www.microsoft.com/technet/security/Bulletin/MS02-001.mspx > discusses some elevation of privilege attacks. It also links to another > article that is supposed to have more details on SID filtering, which > doesn't seem to exist anymore. All references I have found point only > at NT4 and 2000 as susceptible to this kind of attack, and they have a > patch to fix it. So I guess 2003 is secure at least when it comes to > the SIDHistory method. There must be other ways of doing it, though. I > don't know that they could possibly be "simple" if MS put out a patch to > fix this particular hole way back in 02. The referenced article (for > those who don't read it) calls for "a binary edit of the data structures > that hold the SIDHistory information". Not exactly "candy from a baby" > level, unless you happen to be a 3rd level black-belt in > babies-canditsu. But I'm sure someone with extreme skills could take on > an unpatched 2000 domain without much trouble. Either way, it looks > like sidfiltering mitigates most of the risk. > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, > Jorge de > Sent: Friday, September 15, 2006 2:48 AM > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] Elevating privileges from DA to EA > > > Al - we are designing a forest with regional domains (don't ask!) and > one region has suggested it needs to split from this forest since > elevating rights in any regional domain from DA to EA (forest wide) is > 'simple' [and this would break the admin / support model]. > > > > What is being said is very very true. Either you trust ALL Domain Admins > (no matter the domain those are in) or you do not trust ANY! Every > Domain Admin or ANY person with physical access to a DC has the > possibility to turn the complete forest into crap! > > Because if that was NOT the case the DOMAIN would be the security > boundary. Unfortunately it is not! The Forest is the security boundary, > whereas EVERY single DC in the forest MUST be protected and EVERY Domain > Admin MUST be trusted! > > > I am arguing that it is not simple and am looking for methods which > may be used to elevate rights as per the above > > > > When you know HOW, it is as easy as taking candy from a baby > > > > jorge > > > > > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Friday, September 15, 2006 09:36 > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] Elevating privileges from DA to EA > > Thanks for responses, all. > > > > Al - we are designing a forest with regional domains (don't > ask!) and one region has suggested it needs to split from this forest > since elevating rights in any regional domain from DA to EA (forest > wide) is 'simple' [and this would break the admin / support model]. > > > > I am arguing that it is not simple and am looking for methods > which may be used to elevate rights as per the above. > > > > Make sense? > > > > neil > > > > > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick > Sent: 14 September 2006 20:59 > To: ActiveDir@mail.activedir.org > Subject: Re: [ActiveDir] Elevating privileges from DA to EA > > Can you reword? I'm not sure I clearly understand the question. > > > FWIW, going from DA to EA is a matter of adding one's id to the > EA group. DA's have that right in the root domain of the forest (DA's >
Re: [ActiveDir] Elevating privileges from DA to EA
DAs got nothing to do with it. It makes it easier, but this can be done by someone without any account at all. --Paul - Original Message - From: "Bernard, Aric" <[EMAIL PROTECTED]> To: ; Sent: Friday, September 15, 2006 10:33 PM Subject: RE: [ActiveDir] Elevating privileges from DA to EA Kevin, FWIW - as others are stating, assuming you know what you are doing, it is *simple* and painless so long assuming that you are a DA of any domain in the forest and have access to the console of a GC. There are many exploits strategies in this area and in its most basic form this can be done with rudimentary knowledge, native tools, and no coding or scripting. Aric -Original Message- From: "Kevin Brunson" <[EMAIL PROTECTED]> To: "ActiveDir@mail.activedir.org" Sent: 9/15/06 1:35 PM Subject: RE: [ActiveDir] Elevating privileges from DA to EA http://www.microsoft.com/technet/security/Bulletin/MS02-001.mspx discusses some elevation of privilege attacks. It also links to another article that is supposed to have more details on SID filtering, which doesn't seem to exist anymore. All references I have found point only at NT4 and 2000 as susceptible to this kind of attack, and they have a patch to fix it. So I guess 2003 is secure at least when it comes to the SIDHistory method. There must be other ways of doing it, though. I don't know that they could possibly be "simple" if MS put out a patch to fix this particular hole way back in 02. The referenced article (for those who don't read it) calls for "a binary edit of the data structures that hold the SIDHistory information". Not exactly "candy from a baby" level, unless you happen to be a 3rd level black-belt in babies-canditsu. But I'm sure someone with extreme skills could take on an unpatched 2000 domain without much trouble. Either way, it looks like sidfiltering mitigates most of the risk. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Friday, September 15, 2006 2:48 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Elevating privileges from DA to EA Al - we are designing a forest with regional domains (don't ask!) and one region has suggested it needs to split from this forest since elevating rights in any regional domain from DA to EA (forest wide) is 'simple' [and this would break the admin / support model]. What is being said is very very true. Either you trust ALL Domain Admins (no matter the domain those are in) or you do not trust ANY! Every Domain Admin or ANY person with physical access to a DC has the possibility to turn the complete forest into crap! Because if that was NOT the case the DOMAIN would be the security boundary. Unfortunately it is not! The Forest is the security boundary, whereas EVERY single DC in the forest MUST be protected and EVERY Domain Admin MUST be trusted! I am arguing that it is not simple and am looking for methods which may be used to elevate rights as per the above When you know HOW, it is as easy as taking candy from a baby jorge From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, September 15, 2006 09:36 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Elevating privileges from DA to EA Thanks for responses, all. Al - we are designing a forest with regional domains (don't ask!) and one region has suggested it needs to split from this forest since elevating rights in any regional domain from DA to EA (forest wide) is 'simple' [and this would break the admin / support model]. I am arguing that it is not simple and am looking for methods which may be used to elevate rights as per the above. Make sense? neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: 14 September 2006 20:59 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Elevating privileges from DA to EA Can you reword? I'm not sure I clearly understand the question. FWIW, going from DA to EA is a matter of adding one's id to the EA group. DA's have that right in the root domain of the forest (DA's of the root domain have that right). Editing etc. is not necessary. Nor are key-loggers etc. If physical access is available, there are plenty of ways to get the access you require to a domain but I suspect you're asking how can a DA from a child domain gain EA access; is that the question you're looking to answer? Just for curiousity, what brings up that question? Al On 9/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: It has been suggested by certain parties here that elevating one's rights from AD to EA is 'simple'. I have suggested that whilst it's possible it is not simple at all. Does anyone have any descriptions of methods / backdoors / workarounds etc that can be used to elevate rights in this way? Naturally, you may prefe
Re: [ActiveDir] Elevating privileges from DA to EA
It doesn't matter what domain it is in. If you have access to it you can hack it. What you do once you've hacked it is up to you. Jorge and I just tested this and we we able to do some serious damage. It was trivial to delete domain controllers and move FSMO roles and other things, etc. And this applies to both 2000 and 2003. Longhorn's different. One of the easy attack vectors has been removed. I doubt all have, but can't test at the moment as I'm loosing the will to live waiting for applications to open and the ability to double click things (running on a VM ;-) Note. Its likely that any damage caused can be undone, as AD is very flexible in that regard. However the damage caused by someone accessing data or systems that they shouldn't is much worse, and can cause millions of pounds of loss. --Paul - Original Message - From: "Kevin Brunson" <[EMAIL PROTECTED]> To: Sent: Friday, September 15, 2006 9:41 PM Subject: RE: [ActiveDir] Elevating privileges from DA to EA "Elevating priveledges from DA to EA (or from physical DC access to EA) is simple" Is this physical access to a DC in the root domain or physical access to a DC with a forest trust to the root domain? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, September 15, 2006 12:15 PM To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Elevating privileges from DA to EA Hi All I wanted to weigh in with two comments. 1) Elevating priveledges from DA to EA (or from physical DC access to EA) is simple - it takes about 45 minutes and unless you have some very good active monitoring is difficult to detect. There are automated tools out there for doing this. I have been known to use the term lazy EAs to refer to domain admins. 2) Replication boundaries is another reason for separate domains. a million objects can lead to huge DITs and very slow replication - especially in a build a new DC case. Separating that into multiple domains - to put smaller load on locations where bandwidth is an issue is worth considering. For example. 90,000 users. 200 of those are in Alaska The rest of the world has good bandwidth, Alaska locations all have the equivalent of 56K modem speed. DIT and Sysvol size is about 7G, but for Alaska users there are only 3 GPOs that affect them Rather then doing 1 domain I can put the 200 Alaska users in their own domain. Security wise, there is no advantage. Replication wise, the Global Catalgue is a fraction the size of the full database, the Sysvol never replicates anywhere in Alaska,and replicaiton for that domain will cause less strain on their bandwidth - 200 users will create a much lower amount of changes then 90,000 users. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service 202-230-2983 [EMAIL PROTECTED] "Al Mulnick" <[EMAIL PROTECTED] om> To Sent by: ActiveDir@mail.activedir.org [EMAIL PROTECTED] cc ail.activedir.org Subject Re: [ActiveDir] Elevating 09/15/2006 11:34 privileges from DA to EA AM AST Please respond to [EMAIL PROTECTED] tivedir.org I agree and add to that some additional thoughts: Not long ago there was some conversation around a suggestion that [EMAIL PROTECTED] put out regarding the idea of using multiple forests vs. domains in such a model. Personally, I disagree with that recommendation as given. I think A LOT more additional information is required before saying that, but I digress. If you decide to use the multi-domain model, I have to assume that you either have different password policies or a strong layer-8 contingent driving things. If the latter, I hate it for you. If you have a requirement to separate the domains from the forest, your workload just went through the roof, and with that your costs. Was it me I'd want to learn from my past mistakes ;0) and approach this by reversing the conversation. By that I mean I'd want each potential domain owner to absolutely and in a detailed manner specify the functions they need to execute. From there, we'll encompass the rights needed for each of those functions. I think what you'll find is that you can do almost all of it with a single domain if different password policies are not needed (mostly, but you know all of that anyway). From there, I'd be sure to spell all of that out the project sponsor because the costs (both ongoing and up front) can be significant. The amount of complexity and issues with other directory based applications alone can be enough to put them off and actually follow a recommendation such as this. The push obviously is to get as few actual DA
Re: [ActiveDir] Strange password issue
No worries. It's a big thread that has spawned serveral different threads of discussion. --Paul - Original Message - From: Akomolafe, Deji To: ActiveDir@mail.activedir.org Sent: Friday, September 15, 2006 5:32 PM Subject: RE: [ActiveDir] Strange password issue OK. The account under discussion is "512". Had to refresh my brains because I just took your 1-4 bullet points and said, uh-uh, there is a way to have an enabled password-less account. Granted it won't be "512" and will be useless, it is still enabled. Sorry, Paul. Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_(_/ /) (/ Microsoft MVP - Directory Serviceswww.akomolafe.com - we know IT-5.75, -3.23Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: joeSent: Fri 9/15/2006 7:52 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Strange password issue The account is currently 512... You can't get there with a blank password without 1-4. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Akomolafe, DejiSent: Thursday, September 14, 2006 11:52 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Strange password issue I think you are missing 5. 5. The account was created programmatically disabled with PWD_NOT_REQD set. So, we have 546 UAC. Then someone programmatically set UAC to 544 or went into ADUC and manually enabled the account. It's a feasible scenario, no? Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_(_/ /) (/ Microsoft MVP - Directory Serviceswww.akomolafe.com - we know IT-5.75, -3.23Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: joeSent: Thu 9/14/2006 5:25 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Strange password issue The secret is you cannot ENABLE an account with no password if you have a password length policy and the PWD_NOT_REQD flag isn't set. So if you have an account that is created which by default (i.e. no UAC specified) will be 546. If you specify 544 it will still create and it will allow a blank password. If you have an account with 546 (disables, pwdnotrqed) you can clear the pwdnotreqd fine. However when you go to enable the account, you will get busted for not following policy. The Extended Error (-exterr with admod) is DN: CN=someuser,OU=Users,OU=TestOU,DC=test,DC=loc...: [r2dc1.test.loc] Error 0x35 (53) - Unwilling To PerformExtended Error: 052D: SvcErr: DSID-031A0FC0, problem 5003 (WILL_NOT_PERFORM), data 0 Which is F:\DEV\cpp\AdMod>err 52d# for hex 0x52d / decimal 1325 : ERROR_PASSWORD_RESTRICTION winerror.h# Unable to update the password. The value provided for the# new password does not meet the length, complexity, or# history requirement of the domain.# 1 matches found for "52d" A blank password does not have a hash, the system knows it is blank. You will obviously hit the same problem if you have an enabled account with pwd_not_reqd and try to clear the pwd_not_reqd. So current or past setting of UAC has no bearing on this problem. This could occur in four ways that I can think of (in order of likelihood) and speak about 1. Someone relaxed the policy while the password was set or when the account was being enabled / having pwd_not_reqd cleared 2. The Domain Password Policy isn't or at least wasn't getting applied to one or more domain controllers for some reason. Check minPwdLength on the NC Head objects of all DCs in the domain 3. A blank password hash was forced into the attribute of an already enabled account through some form of LSASS process injection. 4. The raw DIT was modified. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul WilliamsSent: Wednesday, September 06, 2006 3:30 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Strange password issue PWD_NOT_REQ is 32. You can create an account with this set and bypass the need to set a password (A
Re: [ActiveDir] Elevating privileges from DA to EA
Lucky you : ) I'm in an environment where we're doing this now, and I'm not happy with how its being done (I think we can be even more secure ;-), which means I've accidently volunteered to re-look at it all for the next iteration of the design cycle... (bollocks) --Paul - Original Message - From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Friday, September 15, 2006 5:22 PM Subject: RE: [ActiveDir] Elevating privileges from DA to EA Thanks Paul., Joe's been there and done it... LOL - so have I several time before :) neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul WilliamsSent: 15 September 2006 09:46To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Elevating privileges from DA to EA Neil, Try a re-read of the first couple of chapters of the first part of the deployment guide book designing and deploying directory and security services. Obviously it doesn't spell out how to do this -it doesn't even allude to how this is done- but does emphasise when and when not to go with the regional domain model. I'm not disputing what anyone is saying here -I agree. I just happen to think the regional model can be a good one, and that if done properly works. Even from a security stand point. The main thing with the regional design is that there's a central group of service admins, or a true delegated model. If you have multiple groups of service admins it can still work, but the issue that has been raised is very real and you probably need to implement processes and monitor against it (if you're forced into such a design by the needs of the business or obtuse upper management ;-). Although it does seem to be possible to implement disparate groups of service admins if you follow the delegation whitepaper (you'll need to improvide, but most of the info. is pertinent), which should put you in a much stronger position from a security stand point. If you can achieve a very small number of people who are actually members of the builtin\Administrators group, and the rest only have delegated permissions and privileges (and preferably very few privileges on the DCs, i.e. no logon locally) you can achieve what you want. Joe's been there and done it... --Paul - Original Message - From: Almeida Pinto, Jorge de To: ActiveDir@mail.activedir.org Sent: Friday, September 15, 2006 8:48 AM Subject: RE: [ActiveDir] Elevating privileges from DA to EA >>>Al - we are designing a forest with regional domains (don't ask!) and one region has suggested it needs to split from this forest since elevating rights in any regional domain from DA to EA (forest wide) is 'simple' [and this would break the admin / support model]. What is being said is very very true. Either you trust ALL Domain Admins (no matter the domain those are in) or you do not trust ANY! Every Domain Admin or ANY person with physical access to a DC has the possibility to turn the complete forest into crap! Because if that was NOT the case the DOMAIN would be the security boundary. Unfortunately it is not! The Forest is the security boundary, whereas EVERY single DC in the forest MUST be protected and EVERY Domain Admin MUST be trusted! >>>I am arguing that it is not simple and am looking for methods which may be used to elevate rights as per the above When you know HOW, it is as easy as taking candy from a baby jorge From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Friday, September 15, 2006 09:36To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Elevating privileges from DA to EA Thanks for responses, all. Al - we are designing a forest with regional domains (don't ask!) and one region has suggested it needs to split from this forest since elevating rights in any regional domain from DA to EA (forest wide) is 'simple' [and this would break the admin / support model]. I am arguing that it is not simple and am looking for methods which may be used to elevate rights as per the above. Make sense? neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: 14 September 2006 20:59To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Elevating privileges from DA to EA Can you reword? I'm not sure I clearly understand the question. FWIW, going from DA to EA is a matter of adding one's id to the EA group. DA's have that right in the root domain of the forest
