[gptalk] Re: Automatic Disabling of AD Computer accounts

  • From: "Nelson, Jamie R Contr 72 CS/SCBAF" <Jamie.Nelson.ctr@xxxxxxxxxxxxx>
  • To: <gptalk@xxxxxxxxxxxxx>
  • Date: Thu, 11 Oct 2007 09:36:48 -0500

Good point...Just run an ADSI script via scheduled task that disables computers 
in the identified OU.

Regards,
Jamie Nelson

-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Thorbjörn Sjövold
Sent: Thursday, October 11, 2007 9:30 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Automatic Disabling of AD Computer accounts

The problem with any type of solution where the local computer is crippled 
instead of working in AD, is that it is hard to undo it, since GP will not be 
applied regardless where in AD it is moved when the time comes to restore the 
computer again J.

 

 

 

 

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Darren Mar-Elia
Sent: den 11 oktober 2007 16:07
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Automatic Disabling of AD Computer accounts

 

I suppose there might be a security setting you could set that would make the 
computer unable to talk to the rest of the domain. Something like an SMB 
Signing setting that is incompatible with your servers/DCs? 

 

darren

 

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Ray Lewis
Sent: Thursday, October 11, 2007 1:57 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Automatic Disabling of AD Computer accounts

 

Thanks Thorbjörn,

 

What about an alternative restriction to prevent the machines being able to 
sign on or being issued a token?

 

I've looked at IPSEC solutions but would prefer to steer clear of this method.

 

 

________________________________

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Thorbjörn Sjövold
Sent: 11 October 2007 09:27
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Automatic Disabling of AD Computer accounts

 

I do not think there are such a solution available, the problem here would be 
that this would be something that need to run in AD and not on the computers 
where the GP CSEs reside and execute, in theory it might be possible for a 
computer to disable itself from a startupscript, but the other way around it 
tough for obvious reasons J. The problem is similar to the situation with the 
Password Policy GP setting that actually executes on the Domain Controllers.

 

 I normally prefer using GP compared to "external" solutions, but a workaround 
could be  a small script or program that runs as a scheduled job on a DC that 
does the trick, although you need to take into consideration that there could 
be disabled computers in other OUs for other reasons etc. Also unless you use 
the DirSync control to monitor changes, you will also have to live with a 
polling solution so it the change will not be immediate. 

 

 

Thorbjörn Sjövold

Special Operations Software

www.specopssoft.com <http://www.specopssoft.com/> 

thorbjorn.sjovold a t specopssoft.com

 

Download our free tool for remote Gpupdate with graphical reporting, 
http://www.specopssoft.com/products/specopsgpupdate/ 
<http://www.specopssoft.com/products/specopsgpupdate/> 

 

 

 

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Ray Lewis
Sent: den 11 oktober 2007 09:38
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Automatic Disabling of AD Computer accounts

 

Hi all...

 

Is there a GPO rule I can tag to an OU that will "automatically" disable the 
computer accounts within it? For example, as soon as a machine is moved into 
that OU, it becomes disabled and cant be re-enabled unless moved.

 

Cheers guys...

 

Ray

***********************
You can unsubscribe from gptalk by sending email to 
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by 
logging into the freelists.org Web interface. Archives for the list are 
available at http://www.freelists.org/archives/gptalk/
************************

Other related posts: