Hi guys

Just wondering is there a techie solutions to this, example like putting on
a logon script for the domain admins or any other priv accounts - that
pauses any logon scripts or override local scripts.

Logon scripts are still performed LSDO (local site domain ou) models isnt
it? So Local logon scripts will be performed first nevertheless?...

Or another simpler workaround would be to query remote servers for logon
scripts before ts to them...

Of course like mentioned below, if you don't trust the machines don't login
with DA accounts - its always the safest.

Thank you and have a splendid day!
 
Kind Regards,
 
Freddy Hartono
Group Support Engineer
InternationalSOS Pte Ltd
mail: [EMAIL PROTECTED]
phone: (+65) 6330-9785
 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Thursday, May 18, 2006 8:22 AM
To: [email protected]
Subject: Re: [ActiveDir] OT: Overriding local computer logon scripts -
anyway to do it?

Wasn't one of the infamous Dr. J stories about how they had attempted to
gain access to one of the msn servers by having a boobie trap script like
that.  If a person had logged in with certain creds it was indeed set to
fire off a script?

Pen test proof of concept story?

joe wrote:

>Absolutely concur. In fact, one of my recommendations to Microsoft for 
>the RODCs that get admin delegation is to disallow domain admin 
>interactive logons to them once the administrator delegation is 
>enabled. Anyone who allows non-DAs onto a DC and then still logs on 
>with their DA ID is asking to be burned at some point.
> 
>Even if MSFT does that, there is still a possible chance the simple 
>attempt at logging on will give the "bad guy" all the info they need to 
>become Enterprise gods which is the whole point of protecting against with
RODCs.
> 
>--
>O'Reilly Active Directory Third Edition - 
>http://www.joeware.net/win/ad3e.htm
> 
> 
>
>  _____
>
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Crawford, 
>Scott
>Sent: Tuesday, May 16, 2006 8:57 AM
>To: [email protected]
>Subject: RE: [ActiveDir] OT: Overriding local computer logon scripts - 
>anyway to do it?
>
>
>"what is stopping some server admins to put in some logon scripts that 
>adds a certain account as enterprise admin (boobietrap)."
> 
>The same thing that prevents them from installing a keylogger or 
>modifying any code on the system to do their nefarious deeds when a 
>high level account runs them - absolutely nothing.  Login scripts are 
>just one of many possible attack vectors.
>
>The point is, if you don't trust the code on a box or the admins that 
>can put code on a box, then you should NEVER use your high-level 
>accounts for accessing that box.
>
>  _____
>
>From: [EMAIL PROTECTED] on behalf of Freddy HARTONO
>Sent: Tue 5/16/2006 3:42 AM
>To: [email protected]
>Subject: [ActiveDir] OT: Overriding local computer logon scripts - 
>anyway to do it?
>
>
>
>Hi all,
>
>I had just logged in one of a printserver in my remote site, out of my 
>usual scope - but the point is that the server has some logon scripts 
>(local) associated with it.
>
>
>Just concerned about the security aspect of it - what is stopping some 
>server admins to put in some logon scripts that adds a certain account 
>as enterprise admin (boobietrap).
>
>I know the usual rule was to not login to untrusted boxes... but is 
>there a way to overcome such?
>
>
>Thank you and have a splendid day! 
>  
>Kind Regards,
>  
>Freddy Hartono
>Group Support Engineer
>InternationalSOS Pte Ltd
>mail: [EMAIL PROTECTED]
>phone: (+65) 6330-9785
>  
>
>  
>

--
Letting your vendors set your risk analysis these days?  
http://www.threatcode.com

List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to