RE: [ActiveDir] Elevating privileges from DA to EA
Not commenting on the elevation of rights strategies - should be clear by now that it is simple once you know what you're doing (and Google will help you and your enemy) But a quick comment on using domains as a replication boundary due to the following statement: Replication wise, the Global Catalgue is a fraction the size of the full database While I agree it may still make sense to have a separate domain to control replication, if you make the DCs a GC, they will certainly replicate much more than a fraction of the size of the full db = from past experience comparing DIT sizes, they will replicate approx. 70% of the data from all other domains in the forest. That's still a lot of data on a GC - so if the domain with 90.000 users has a DIT of approx. 5 GB, a GC in the Alaska domain would likely still be 3.5 GB in size, while a DC would hardly be more than 40 MB. The more important point is, that most of the data in the GC is fairly static, so that it shouldn't cause too much replication traffic. And if the same guys manage that manage your main domain also manage the Alaska domain (and no one else gets domain admin rights in the Alaska domain), you're not really increasing your attack surface either. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, September 15, 2006 7:15 PM To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Elevating privileges from DA to EA Hi All I wanted to weigh in with two comments. 1) Elevating priveledges from DA to EA (or from physical DC access to EA) is simple - it takes about 45 minutes and unless you have some very good active monitoring is difficult to detect. There are automated tools out there for doing this. I have been known to use the term lazy EAs to refer to domain admins. 2) Replication boundaries is another reason for separate domains. a million objects can lead to huge DITs and very slow replication - especially in a build a new DC case. Separating that into multiple domains - to put smaller load on locations where bandwidth is an issue is worth considering. For example. 90,000 users. 200 of those are in Alaska The rest of the world has good bandwidth, Alaska locations all have the equivalent of 56K modem speed. DIT and Sysvol size is about 7G, but for Alaska users there are only 3 GPOs that affect them Rather then doing 1 domain I can put the 200 Alaska users in their own domain. Security wise, there is no advantage. Replication wise, the Global Catalgue is a fraction the size of the full database, the Sysvol never replicates anywhere in Alaska,and replicaiton for that domain will cause less strain on their bandwidth - 200 users will create a much lower amount of changes then 90,000 users. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service 202-230-2983 [EMAIL PROTECTED] Al Mulnick [EMAIL PROTECTED] om To Sent by: ActiveDir@mail.activedir.org [EMAIL PROTECTED] cc ail.activedir.org Subject Re: [ActiveDir] Elevating 09/15/2006 11:34 privileges from DA to EA AM AST Please respond to [EMAIL PROTECTED] tivedir.org I agree and add to that some additional thoughts: Not long ago there was some conversation around a suggestion that [EMAIL PROTECTED] put out regarding the idea of using multiple forests vs. domains in such a model. Personally, I disagree with that recommendation as given. I think A LOT more additional information is required before saying that, but I digress. If you decide to use the multi-domain model, I have to assume that you either have different password policies or a strong layer-8 contingent driving things. If the latter, I hate it for you. If you have a requirement to separate the domains from the forest, your workload just went through the roof, and with that your costs. Was it me I'd want to learn from my past mistakes ;0) and approach this by reversing the conversation. By that I mean I'd want each potential domain owner to absolutely and in a detailed manner specify the functions they need to execute. From there, we'll encompass the rights needed for each of those functions. I think what you'll find is that you can do almost all of it with a single domain if different password policies are not needed (mostly, but you know all of that anyway). From there, I'd be sure to spell all of that out the project sponsor because the costs (both ongoing and up front) can be significant. The amount of complexity and issues with other directory based applications alone can be enough to put them off and actually follow a recommendation such as this. The push
RE: [ActiveDir] Elevating privileges from DA to EA
and that's kinda where the original post came from - I've been thru this exercise with other orgs and feel the need to re-visit every so often, esp. when I move on to another org. BTW: I really appreciate all the feedback and I didn't expect any specific hacks to be made public (just to appear joe :) Many thanks to all. neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: 17 September 2006 16:04To: ActiveDir@mail.activedir.orgSubject: 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
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 (DA's of the root domain have
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: ActiveDir@mail.activedir.org 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
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: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org 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 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
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: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org 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 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
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: ActiveDir@mail.activedir.org 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
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 admin / support model
RE: [ActiveDir] Elevating privileges from DA to EA
With the IFM feature in 2003 the promotion issue is not that much of an issue. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 -Original Message- From: [EMAIL PROTECTED] [mailto:ActiveDir- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, September 15, 2006 1: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's as possible. Is the threat real? Yes. If you feel you should have multiple domains, chances are good you really need OU's and a better admin model that includes less complexity and fewer moving parts. Oh, one other thing that might be of interst to your planning group: ask them about their restoration requirements. In that model, restoration can be a bloody nightmare especially if the layer-8 issues are not resolved up front. Al On 9/15/06, Paul Williams [EMAIL PROTECTED] wrote: 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
RE: [ActiveDir] Elevating privileges from DA to EA
Another example of that regional forest type model Ive noticed dealing in the state/local space is that sometimes you have organizations like the police/sheriff or an auditor which has to be separate. You end up standing up a forest for a hundred users or something, but, those groups always have the same (and solid) argument. Its not political really, just if you look at it from a high level they need to limit who has access to their data. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, September 15, 2006 10:32 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Elevating privileges from DA to EA I am the type that argues that 3-5 EA/DA folksis good for any size org. Showing that the large companies with hundreds of thousands of seats can accomplish it helps illustrate that smaller companies should be able to accomplish it and that instead of making the job harder,it makes it easier. It may be tougher up front while you fight the political battles and learn how your environment and processes really work but once that is done, life is much easier as AD doesn't tend to just break on its own, people screw up. The less chances available for those screwups the smoother things run. When I see companies with tens or hundreds or even thousands of folks with admin (or other native built in group) access in a forest I just get an upset stomach because I know that things are almost certainly not running as smoothly as they could be. In fact, from my experiences, the more admins there are, it seems the more harried and running they all are. Getting down to a few EA/DAs is all about process and automation. Do it right, it is feasible and works great. Do it wrong, you have admins burning out every 3 months. I understand that admins don't have time to automate things and make the environment better. I have been in similar positions, positions where I had no choice but to work 80-100 a week every week always carrying a pager, etc. When in those positions I made the conscious choice to make sure I found a little time every day (even 30 minutes) to do some little bit. This slowly adds up. If you attack the items you are spending the most time on during the day, you slowly start freeing yourself up more and more and if it is to automate something that is being done manually more than likely you are saving even more time when that something is done correctly and consistently every time (everyone makes mistakes when doing things manually). Absolutely you need to be running separate admin and normal user IDs for admins. You could be the best admin in the world but it is stupid not to take care to make sure that if for some reason you make some small slip, the chances are reduced that something bad can result. My general recommendation is normal ID and dollar sign ID, e.g. jricha34 and $jricha34. Maybe even going to double dollar for enterprise admin to make that stand out even more so jricha34,$jricha34, and $$jricha34. Also make sure that these IDs are not used interactively on workstations and avoid logging into any servers that you don't fully trust (i.e. you own and only the DAs can log into or manipulate). Now for the regional forest... I haven't heard a good reason for one yet. I haven't heard a good reason for separate DAs for geographies. The best reasons I have heard are in relation to divisions within a company, say like a financial division of a company that's main business is manufacturing or distribution or something. The banking laws in some companies can be a bit involved and in _some_ of those cases there may be a need for a separate forest. There needs to be really good documentation of all of the why's though.A company is often better served as a whole if divisions and geographies bow down and let one group handle the overall functioning of the AD service. Assuming the group doing the work actually knows what it is doing, things will usually be much better off. Politics tends to get in the way here until someone gets sick of the politics and either makes an executive decision or stages a coup and forcefully takes control. I am with James that policy and replication boundaries are valid reasons for separate domains. Perfect world is single forest domain, things from Microsoft just work better in those environments. But as James pointed out with his example, with the current replication model, a single domain forest just can't work sometimes even if the policy is the same in all domains. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Hargraves Sent: Friday, September 15, 2006 12:22 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Elevating privileges from DA to EA I agree with the people who are saying Either trust
Re: [ActiveDir] Elevating privileges from DA to EA
Replication is certainly a good reason to separate. Not a common one however from what I've seen. African continentmight be in a similar boat for some international companies. There are some other reasons as well, but they have been very far and few between from my experience. I can't talk to the others with any credibility. 56K? That's being optimistic isn't it? Some of the ones I've seen for some other government offices was more like 9.6 on a good day :) On 9/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi AllI 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 goodactive monitoring is difficult to detect.There are automated tools outthere 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.amillion 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 worthconsidering.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 only3 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, theGlobal Catalgue is a fraction the size of the full database, the Sysvolnever replicates anywhere in Alaska,and replicaiton for that domain will cause less strain on their bandwidth - 200 users will create amuch lower amount of changes then 90,000 users.Regards;James R. DayActive Directory Core TeamOffice of the Chief Information Officer National Park Service202-230-2983[EMAIL PROTECTED]Al Mulnick [EMAIL PROTECTED]omToSent by:ActiveDir@mail.activedir.org [EMAIL PROTECTED]ccail.activedir.orgSubject Re: [ActiveDir] Elevating09/15/2006 11:34privileges from DA to EAAM ASTPlease respond to [EMAIL PROTECTED] tivedir.orgI 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 forestsvs. domains in such a model.Personally, I disagree with thatrecommendation 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 youeither have different password policies or a strong layer-8 contingentdriving things. If the latter, I hate it for you. If you have a requirement to separate the domains from the forest, yourworkload 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 domainowner to absolutely and in a detailed manner specify the functions theyneed 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 ofit 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 upfront) can be significant.The amount of complexity and issues with otherdirectory based applications alone can be enough to put them off and actually follow a recommendation such as this. The push obviously is to getas few actual DA's as possible.Is the threat real? Yes.If you feel you should have multiple domains,chances are good you really need OU's and a better admin model that includes less complexity and fewer moving parts.Oh, one other thing that might be of interst to your planning group: askthem about their restoration requirements.In that model, restoration canbe a bloody nightmare especially if the layer-8 issues are not resolved up front.AlOn 9/15/06, Paul Williams [EMAIL PROTECTED] wrote: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 securityservices.Obviously it doesn't spell out how to do this -it doesn't evenallude 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 tothink the regional model can be a good one, and that if done properlyworks.Even from a security stand point.The main thing with the regional design is that there's a central group of service admins, or atrue delegated model.If you have multiple groups of service admins it can still work, but theissue that has been raised is very real and you probably need to implement processes and monitor against it (if you're forced into such adesign by the needs of the business or
RE: [ActiveDir] Elevating privileges from DA to EA
Elevating priveledges from DA to EA (or from physical DC access to EA) is simple This requires physical access to any DC in the same forest. A cross forest / cross domain trust would require some additional configuration done to the forest to be able to do the same thing. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service 202-230-2983 [EMAIL PROTECTED] Kevin Brunson [EMAIL PROTECTED] undtech.com To Sent by: ActiveDir@mail.activedir.org [EMAIL PROTECTED] cc ail.activedir.org Subject RE: [ActiveDir] Elevating 09/15/2006 03:41 privileges from DA to EA PM EST Please respond to [EMAIL PROTECTED] tivedir.org 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
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 (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 prefer to send this to me offline :) [
[EMAIL PROTECTED]]
I can think of the following basic methods:
- Remove DC disks and edit offline
- Introduce key logger on admin workstation
/ DC - Inject code into lsass
As you can see, I don't want specific steps to
'hack' the DC, just basic ideas / methods.
Thanks, 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.
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] 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
(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 prefer to send this to me offline :) [
[EMAIL PROTECTED]]
I can think of the following basic
methods: - Remove DC disks and edit
offline - Introduce key logger on
admin workstation / DC - Inject
code into lsass
As you can see, I don't want specific steps to
'hack' the DC, just basic ideas / methods.
Thanks, 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.
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
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 (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 prefer to send this to me offline :) [ [EMAIL PROTECTED]] I can think of the following basic methods: - Remove DC disks and edit offline - Introduce key logger on admin workstation / DC
Re: [ActiveDir] Elevating privileges from DA to EA
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's as possible. Is the threat real? Yes. If you feel you should have multiple domains, chances are good you really need OU's and a better admin model that includes less complexity and fewer moving parts. Oh, one other thing that might be of interst to your planning group: ask them about their restoration requirements. In that model, restoration can be a bloody nightmare especially if the layer-8 issues are not resolved up front. AlOn 9/15/06, Paul Williams [EMAIL PROTECTED] wrote: 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
Re: [ActiveDir] Elevating privileges from DA to EA
I agree with the people who are saying Either trust all of them or none of them. Realistically, unless you have a large environment (BTW, some people argue that all but maybe 10 Fortune 100 companies are 'medium' sized and the other 99.% of organizations are 'small'), there should only be a handful of people (3-7?) and some service accounts that require that level of rights.Domain/Enterprise Admins are a tricky bunch and no matter what you do to us, we can take back whatever rights you took away from us very easily, then lock you and everyone else in the world out, destroy the on-site backups and demolish the environment to where it's going to take a major effort to get back to operational status. This would take all take significantly less time than it would take for someone to figure out who is doing what. I like Joe's recommendation of taking everyone that you don't need out of the admins groups and simply granting them various levels of rights with their account. Possibly give everyone a user and admin account (user1234567 and user1234567a), heaven knows it would make troubleshooting a lot easier. That being said, someone asking for their own regional forest? Fine, as long as the person saying that it's necessary is willing to come up with the budget for the additional servers and additional personnel to support that forest and that they understand that they will have 0 admin level rights on anything in the 'main' forest, it wouldn't bother me, just one less thing that I have to worry about managing. Oh yeah, and they have to pay for yearly audits to validate that they are meeting the corporate standards for security at all levels. Then again, most of those items aren't usually my concern. Thank God I'm not in management :DOn 9/15/06, Paul Williams [EMAIL PROTECTED] wrote: 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
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 (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
Re: [ActiveDir] Elevating privileges from DA to EA
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: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 prefer to send this to me offline :) [ [EMAIL PROTECTED] I can think of the following basic methods: - Remove DC disks and edit offline - Introduce key logger on admin workstation / DC - Inject code into lsass As you can see, I don't want specific steps to 'hack' the DC, just basic ideas / methods. Thanks, 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
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's as possible. Is the threat real? Yes. If you feel you should have multiple domains, chances are good you really need OU's and a better admin model that includes less complexity and fewer moving parts. Oh, one other thing that might be of interst to your planning group: ask them about their restoration requirements. In that model, restoration can be a bloody nightmare especially if the layer-8 issues are not resolved up front. Al On 9/15/06, Paul Williams [EMAIL PROTECTED] wrote: 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
RE: [ActiveDir] Elevating privileges from DA to EA
Again simple is relative. Also don't mistake your knowledge for that of anyone else. You may know more than others, others may know more than you. Me, I tend to expect others know more than I do so I error on the side of caution because I know what I know and it sometimes scares me. :o) Hopefully no one herewill feel the need togive any more detail,hints, or speculations on methods that can be used to compromise Active Directory. It is not a good open forum discussion item. If someones comes to you and gives you detailed hacking instructions (for free or with a charge), start to wonder what other bad habits they have as well. :) Just trust that such things are possible, people do do this both for good[1] and bad reasons, you aren't blocking them so don't be giving out hefty rights on DCs in your forest that you don't trust 100%. joe p.s.A basic security premise is that you can't prove systems secure, only insecure. [1] Consider a company that is insourcing their environment from a vendor who doesn't want to give up the forest... I think someone posted to this very list this year about a vendor who found out that was going to happen and they chopped off access to the forest root from the customer network leaving the customer high and dry. The customer should have had a root DC in their possession before making that announcement. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin BrunsonSent: Friday, September 15, 2006 2:03 PMTo: ActiveDir@mail.activedir.orgSubject: 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 doesnt 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 dont 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 dont 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 Im 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 deSent: Friday, September 15, 2006 2:48 AMTo: ActiveDir@mail.activedir.orgSubject: 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
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 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 prefer to send this to me
RE: [ActiveDir] Elevating privileges from DA to EA
I am the type that argues that 3-5 EA/DA folksis good for any size org. Showing that the large companies with hundreds of thousands of seats can accomplish it helps illustrate that smaller companies should be able to accomplish it and that instead of making the job harder,it makes it easier. It may be tougher up front while you fight the political battles and learn how your environment and processes really work but once that is done, life is much easier as AD doesn't tend to just break on its own, people screw up. The less chances available for those screwups the smoother things run. When I see companies with tens or hundreds or even thousands of folks with admin (or other native built in group) access in a forest I just get an upset stomach because I know that things are almost certainly not running as smoothly as they could be. In fact, from my experiences, the more admins there are, it seems the more harried and running they all are. Getting down to a few EA/DAs is all about process and automation. Do it right, it is feasible and works great. Do it wrong, you have admins burning out every 3 months. I understand that admins don't have time to automate things and make the environment better. I have been in similar positions, positions where I had no choice but to work 80-100 a week every week always carrying a pager, etc. When in those positions I made the conscious choice to make sure I found a little time every day (even 30 minutes) to do some little bit. This slowly adds up. If you attack the items you are spending the most time on during the day, you slowly start freeing yourself up more and more and if it is to automate something that is being done manually more than likely you are saving even more time when that something is done correctly and consistently every time (everyone makes mistakes when doing things manually). Absolutely you need to be running separate admin and normal user IDs for admins. You could be the best admin in the world but it is stupid not to take care to make sure that if for some reason you make some small slip, the chances are reduced that something bad can result. My general recommendation is normal ID and dollar sign ID, e.g. jricha34 and $jricha34. Maybe even going to double dollar for enterprise admin to make that stand out even more so jricha34,$jricha34, and $$jricha34. Also make sure that these IDs are not used interactively on workstations and avoid logging into any servers that you don't fully trust (i.e. you own and only the DAs can log into or manipulate). Now for the regional forest... I haven't heard a good reason for one yet. I haven't heard a good reason for separate DAs for geographies. The best reasons I have heard are in relation to divisions within a company, say like a financial division of a company that's main business is manufacturing or distribution or something. The banking laws in some companies can be a bit involved and in _some_ of those cases there may be a need for a separate forest. There needs to be really good documentation of all of the why's though.A company is often better served as a whole if divisions and geographies bow down and let one group handle the overall functioning of the AD service. Assuming the group doing the work actually knows what it is doing, things will usually be much better off. Politics tends to get in the way here until someone gets sick of the politics and either makes an executive decision or stages a coup and forcefully takes control. I am with James that policy and replication boundaries are valid reasons for separate domains. Perfect world is single forest domain, things from Microsoft just work better in those environments. But as James pointed out with his example, with the current replication model, a single domain forest just can't work sometimes even if the policy is the same in all domains. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt HargravesSent: Friday, September 15, 2006 12:22 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Elevating privileges from DA to EA I agree with the people who are saying "Either trust all of them or none of them". Realistically, unless you have a large environment (BTW, some people argue that all but maybe 10 Fortune 100 companies are 'medium' sized and the other 99.% of organizations are 'small'), there should only be a handful of people (3-7?) and some service accounts that require that level of rights.Domain/Enterprise Admins are a tricky bunch and no matter what you do to us, we can take back whatever rights you took away from us very easily, then lock you and everyone else in the world out, destroy the on-site backups and demolish the environment to where it's going to take a major effort to get back to operational status. This would take all take significa
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 prefer to send this to me offline :) [
[EMAIL PROTECTED]]
I can think of the following basic methods:
- Remove DC disks and edit offline
- Introduce key logger on admin workstation / DC
- Inject code into lsass
As you can see, I don't want specific steps to 'hack' the DC, just basic ideas / methods.
Thanks,
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] Elevating privileges from DA to EA
Title: Elevating privileges from DA to EA
Oh its easier than you think go look at the ACLs on some
objects and think about what the various system accounts run as over the
network on the DCs.
Thanks,
Brian Desmond
[EMAIL PROTECTED]
c - 312.731.3132
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Thursday, September 14, 2006 12:14 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Elevating privileges from DA to EA
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 prefer to send this to me
offline :) [EMAIL PROTECTED]
I can think
of the following basic methods:
- Remove
DC disks and edit offline
-
Introduce key logger on admin workstation / DC
- Inject
code into lsass
As you can
see, I don't want specific steps to 'hack' the DC, just basic ideas / methods.
Thanks,
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] Elevating privileges from DA to EA
Title: Elevating privileges from DA to EA
Simple is a relative term but yes, there are mechanisms
that could be and aretermed simple.
No I don't think people shouldn't be sharing details even
offline. If someonecannot come up with a method on their own it
doesn't mean someone else who is aware of a method should supply it. It doesn't
help anything knowing how itcan
bedone.
You are a smart guy though Neil, I have no doubt if you sat
down and gave yourself an hour to think out the ways an attack could be
perpetrated you could work out a couple of methods that you would consider
simple.
Hopefully folks don't start dropping hints, etc as it is a
can of worms we don't generally want opened up.
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: Thursday, September 14, 2006 12:14
PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir]
Elevating privileges from DA to EA
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 prefer to send this to me offline :)
[EMAIL PROTECTED]
I can think of the following basic methods:
- Remove DC disks and edit offline
- Introduce key logger on admin workstation /
DC - Inject code into lsass
As you can see, I don't want specific steps to 'hack'
the DC, just basic ideas / methods.
Thanks, 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.
