We don't use the separate account to protect against hackers trying to gain
access to the admin level accounts. It is to cut down on the accidental
virus infections and such. The $ IDs don't get email access (except for the
few people doing email support) so if they get a nice happy virus in the
mail, they may possibly infect their machine and some network shares, no
server root drives, nor tearing up AD if someone puts out an AD aware virus.

On the separate passwords thing I agree with you however if someone wants to
fix that they can. Use pwdump3 or something like that to dump hashes and do
compares of the hashes between the two accounts, if they come out the same,
expire the admin ID and make them change it. This would be pretty easily
scripted. 

As for protecting the userid names from hackers, depending on what is being
delegated to those IDs, it may be possible to find out what they are by
looking at the permissions or rights or within certain groups unless the
lockdown is so tight that SID enumeration can't happen at all. 


  joe

 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO
(HP-Germany,ex1)
Sent: Tuesday, January 06, 2004 2:39 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Wierd issue with security descriptor reverting on
replication

I also tend to use a prefix for admin accounts, however you can debate if
this really makes sense. It's definitely user-friendly as the user only has
to remember one account and then one pre- or postfix when he wants to use
the admin-version of this account.  And you shouldn't believe that the users
will use different passwords...

However, this approach also shows which account you ought to attack if you
want to gain higher privileges...  This is one of the reasons, why in
addition to creating separte OUs for the admin accounts, I hide these
special OUs in AD so that the normal Authenticated User can't browse or
query for all accounts with a special prefix - naturally, the OU is
configured to be visible to the Admins themselves, but even here we make a
differentiation who can see which admins (viewing the OU with the domain
admin accounts is more restricted than viewing OUs with OU admin accounts)

/Guido

-----Original Message-----
From: Roger Seielstad [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 6. Januar 2004 16:16
To: '[EMAIL PROTECTED]'
Subject: RE: [ActiveDir] Wierd issue with security descriptor reverting on
replication

WE use 3 character prefixes ourselves, but the same basic result.

--------------------------------------------------------------
Roger D. Seielstad - MTS MCSE MS-MVP
Sr. Systems Administrator
Inovis Inc.


> -----Original Message-----
> From: Joe [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 06, 2004 8:23 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] Wierd issue with security descriptor 
> reverting on replication
> 
> 
> I agree with Guido. In fact any ID that has any delegated rights in 
> our AD gets it on an ID called a $-ID. It is their normal userid 
> prefixed with a $.
> That way they all sort to the top when sorted and it is really obvious 
> when they are being used. I have been using $ ID's (and $$ ID's for 
> domain admins
> - to indicate even more power that isn't delegated) for about
> 7 years now,
> it works fine though I have run into people who say it doesn't for 
> some odd reason. I think they just feel uncomfortable with the special 
> character in the name.
> 
>   joe
> 
>  
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> GRILLENMEIER,GUIDO
> (HP-Germany,ex1)
> Sent: Tuesday, January 06, 2004 6:50 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] Wierd issue with security descriptor 
> reverting on replication
> 
> yes, the adminSDholder is good for these kind of surprises, but the 
> main reason it exists is that you don't accidentally grand a 
> "downlevel"
> group/user enough permissions to reset the PW on a highly priviledged 
> account - thus compromising security.
> 
> You should definitely go with the "separate admin account" 
> model - this is
> not just for enterprise or domain admins protected by the 
> adminSDholder, but also for lower level OU or data admins, which could 
> otherwise be compromised as well by a simple helpdesk user who is 
> allowed to reset PW at the specific OU level containing your "lower 
> level" admins...
> 
> Rgd. your name in the from field when sending eMail: this is less up 
> to you, than your Exchange Admins (unless you are the same guy).
> Seems like your
> Exchange folks have configured your SMTP GW servers to remove the 
> Display-Name and only to reveal the eMail address instead. I actually 
> preferr it this way, instead of showing a somewhat obscure Display 
> Name (meant for internal handling of accounts) to the outside world, 
> like we do it...
> 
> /Guido
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 6. Januar 2004 08:13
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] Wierd issue with security descriptor 
> reverting on replication
> 
> That looks like it might be the culprit.  I need to do a little bit 
> more checking and see if there are any exceptions, but this seems like 
> the most logical explanation and so far it has born out.
> 
> I think we can fix this as the admins are SUPPOSED to be using special 
> accounts for admin work and most of our applications that require 
> special permissions shouldn't run on these users.
> 
> Now, if I could figure out how to make my name show up in the from 
> field when mailing to the list from Outlook, I'd be all set :)
> 
> Thanks!
> 
> Joe K.
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Joe
> Sent: Monday, January 05, 2004 11:43 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] Wierd issue with security descriptor 
> reverting on replication
> 
> Joe it sounds like you are being bitten by adminSDHolder. 
> Poke around for it
> (archives for here and the newsgroups and MSKB) you will find 
> considerable info on it now.
> 
> Basically there is a process that goes through and protects certain 
> accounts (usually admin type accounts like Ent Admins, Dom Admins, 
> Admins, Acc Ops, Serv Ops, etc) by removing the inherit flag and 
> setting the ACL to the ACL of the adminSDHolder object in the system 
> container. Once you "clean up"
> an
> ID you should see it reset in about 5-10 minutes. 
> 
> Check to see if you have the admincount attribute populated on these 
> ID's, that is the flag for the process. Any groups that the users are 
> in that have that flag set will force the user to get that flag set as 
> well.
> 
>   joe
> 
> 
> 
> This message is for the designated recipient only and may contain 
> privileged, proprietary, or otherwise private information.
> If you have
> received it in error, please notify the sender immediately and delete 
> the original.  Any other use of the email by you is prohibited.
> List info   : http://www.activedir.org/mail_list.htm
> List FAQ    : http://www.activedir.org/list_faq.htm
> List archive: 
> http://www.mail-archive.com/activedir%> 40mail.activedir.org/
> 
> List info   : 
> http://www.activedir.org/mail_list.htm
> List FAQ    : http://www.activedir.org/list_faq.htm
> List archive: 
> http://www.mail-archive.com/activedir%> 40mail.activedir.org/
> 
> 
> List info   : 
> http://www.activedir.org/mail_list.htm
> List FAQ    : http://www.activedir.org/list_faq.htm
> List archive: 
> http://www.mail-archive.com/activedir%> 40mail.activedir.org/
> 
List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to