| Author | Messages | |
gabriel/tfi
Posts:381
 | | 01/03/2009 7:22 PM |
| I second this idea.
Even though the general rule in Security is DenyALL-AllowSOME, with RODC I
would focus and put effort on securing sensitive users/computers ("Denied
RODC Password Replication Group") rather than bumping my head to determine
what user/computer passwords will be cached at a certain BO-RODC
(RODC-specific msDS-Reveal-OnDemandGroup).
I've also noticed that roaming users usually visits the same bunch of sites.
Of course it would be a completely different story if a security policy
clearly mandates higher security standards.
Also, I've not found a good reason yet to pre-populate cached passwords into
the RODC.
Gabriele.
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-
> owner@mail.activedir.org] On Behalf Of Akomolafe, Deji
> Sent: venerdì 2 gennaio 2009 23.31
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] RODC and computer accounts that are allowed to
> have their creds replicated.
>
> My idea (because of the inherent security enforced through the DENY
> group) is to cache everything IF you are going to be using RODC and you
> have a lot of travelling users. Could be the lazy approach, but in the
> absence of a provisioning/deprovision system, I have found this to be
> the least cumbersome administrative approach.
>
>
> Sincerely,
> _____
> (, / | /) /) /)
> /---| (/_ ______ ___// _ // _
> ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
> (_/ /)
> (/
> www.akomolafe.name<http://www.akomolafe.name/> - we know IT -5.75, -
> 3.23 Do you now realize that Today is the Tomorrow you were worried
> about Yesterday? -anon ________________________________
> From: ActiveDir-owner@mail.activedir.org [ActiveDir-
> owner@mail.activedir.org] On Behalf Of Laura E. Hunter
> [laurahcomputing@gmail.com]
> Sent: Friday, January 02, 2009 1:45 PM
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] RODC and computer accounts that are allowed to
> have their creds replicated.
>
> Lifecycle management of RODC password caching will become a more
> visible issue as they (RODCs) become more widely deployed, I think.
> The RODC Branch Office Guide offers, if I recall, very broad stroke
> advice of:
>
> "Take one of the following two approaches:
>
> * Cache everything (except for the Domain-wide DENY groups)
>
> * Cache only those user/computer groups that are specifically required
> for each RODC
>
> "
>
> It's the typical "Security vs. Usability" debate - the former is easier
> to manage, but has the potential to have a user account cached on RODC1
> when they haven't logged onto a computer in Branch1 in 6 months/9
> months/a year. The latter minimizes the # of user/computer accounts
> whose information could be exposed in the case of a compromised/stolen
> RODC, but becomes more difficult to manage without scripting and/or
> some kind of automated IdM solution.
> On Fri, Jan 2, 2009 at 4:20 PM, Jorge de Almeida Pinto
> <Jorge.deAlmeidaPinto@oxfordcomputergroup.com<mailto:Jorge.deAlmeidaPin
> to@oxfordcomputergroup.com>> wrote:
>
> The specific risk is that the password of all computer accounts is
> still distributed on all RODCs. I would still use the specific allow
> group for a particular RODC and automate the group membership in some
> way using scripts or your IdAM solution (e.g. ILM) if you already have
> such.
>
>
>
> Passwords of powerful accounts (DCs, domain admins, etc) are NEVER
> replicated to RODCs because certain security principals (groups, users)
> are member of the Domain Wide DENY group. The DENY group ALWAYS
> overrides any membership in the ALLOW group.
>
>
>
> Met vriendelijke groeten / Kind regards,
>
>
>
> Ing. Jorge de Almeida Pinto
>
> Senior Technical Consultant
>
> MVP Identity & Access - Directory Services
>
>
>
> Oxford Computer Group Benelux
>
> *: +31 (0)6 26.26.62.80 | *: +31 (0)70 36.21.045 | 7: +31 (0)70
> 36.21.677
> *: Sweelinckplein 9 - 11 (unit 11), 2517 GK, Den Haag, The Netherlands
> (Google
> Maps<http://maps.google.com/maps?f=q&hl=EN&geocode=&q=sweelinckplein+9+
> -+11+(unit+11),+2517+GK,+Den+Haag,+The+Netherlands&sll=37.0625,-
> 95.677068&sspn=50.291089,113.90625&ie=UTF8&z=16&g=sweelinckplein+9+-
> +11+(unit+11),+2517+GK,+Den+Haag,+The+Netherlands> (Live
> Maps<http://maps.live.com/default.aspx?v=2&FORM=LMLTCC&cp=52.084005~4.2
> 85932&style=r&lvl=14&tilt=-90&dir=0&alt=-
> 1000&phx=0&phy=0&phscl=1&where1=Sweelinckplein%209%20-
> %2011%20(unit%2011)%2C%202517%20GK%2C%20Den%20Haag%2C%20The%20Netherlan
> ds&encType=1>
> www.oxfordcomputergroup.com | Expertise in Identity & Access Management
>
> Registered nr Chamber of Commerce/KvK 32129259, VAT/BTW
> NL8188.31.972.BO1
>
>
>
> [cid:image001.png@01C96D28.4340A800]
>
> ________________________________________________________________
>
> MVP Profile --> https://mvp.support.microsoft.com/profile/jorge1
>
> MVP Home Site --> https://mvp.support.microsoft.com/
>
> MVP Overview --> https://mvp.support.microsoft.com/mvpexecsum
>
> BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
>
> ________________________________________________________________
>
>
>
> From: ActiveDir-owner@mail.activedir.org<mailto:ActiveDir-
> owner@mail.activedir.org> [mailto:ActiveDir-
> owner@mail.activedir.org<mailto:ActiveDir-owner@mail.activedir.org>] On
> Behalf Of Tony Gordon
> Sent: Friday, January 02, 2009 21:36
>
> To: ActiveDir@mail.activedir.org<mailto:ActiveDir@mail.activedir.org>
> Subject: [ActiveDir] RODC and computer accounts that are allowed to
> have their creds replicated.
>
>
>
> We are planning to deploy RODCs to the regional offices. We have a
> relatively painless way to automatically populate the groups that allow
> "caching" the creds with the user accounts for each RODC. Computer
> accounts present more of a challenge. One of the thoughts is to just
> put domain computers group into the "Allowed RODC Password Replication"
> Group.
>
> What are the specific risks we would be incurring in that scenario?
>
> Is there a scenario where another DC (RO or RW) would auth to a
> particular RODC and in doing so cause to have its password replicated
> to an RODC?
>
> How did other people that deployed RODCs dealt with this issue.
>
> Thank you, Tony.
>
> [cid:image002.gif@01C96D28.4340A800]
> Tony Gordon
> Windows 2003 & 2000 MCSE, Windows 2003 MCSA, PMP ITS Infrastructure
> Engineering Hewitt Associates | 100 Half Day Road | Lincolnshire,
> IL 60069 | USA Tel 847.295.5000 x50526 | Fax 847.554.1574 tony
> dot gordon at hewitt dot com | www.hewitt.com<http://www.hewitt.com/>
>
> ________________________________
>
> The information contained in this e-mail and any accompanying documents
> may contain information that is confidential or otherwise protected
> from disclosure. If you are not the intended recipient of this message,
> or if this message has been addressed to you in error, please
> immediately alert the sender by reply e-mail and then delete this
> message, including any attachments. Any dissemination, distribution or
> other use of the contents of this message by anyone other than the
> intended recipient is strictly prohibited. All messages sent to and
> from this e-mail address may be monitored as permitted by applicable
> law and regulations to ensure compliance with our internal policies and
> to protect our business. E-mails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, amended, lost
> or destroyed, or contain viruses. You are deemed to have accepted these
> risks if you communicate with us by e-mail.
>
>
>
> __________ Information from ESET Smart Security, version of virus
> signature database 3732 (20090102) __________
>
>
>
> The message was checked by ESET Smart Security.
>
>
>
> http://www.eset.com<http://www.eset.com/>
>
>
> __________ Information from ESET Smart Security, version of virus
> signature database 3732 (20090102) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com<http://www.eset.com/>
>
>
>
> --
> -----------------------
> Laura E. Hunter
> Architect, Oxford Computer Group (http://www.oxfordcomputergroup.com)
> Microsoft MVP, Directory Services
> (https://mvp.support.microsoft.com/profile/laura)
> Author, Active Directory Consultant's Field Guide
> (http://tinyurl.com/7f8ll) Author, Active Directory Cookbook, Third
> Edition (http://tinyurl.com/7kp3ct)
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
| | | |
|
|