I have a vbscript that check the entire AD for a specific computer name,
and then the script deletes the computer name.

What security measures can I put in place so Domain Controllers or
member servers are not deleted ?



I am a little concerned here !

Thanks for any help.

sputnik wrote:

> I have a vbscript that check the entire AD for a specific computer name,
> and then the script deletes the computer name.
>
> What security measures can I put in place so Domain Controllers or member
> servers are not deleted ?
>
> I am a little concerned here !

Your script can check the operatingSystem attribute to make sure the string
"server" is not found. I would make the check case insensitive (by using
LCase for example).

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

"Richard Mueller [MVP]" <rlmueller-nospam@xxxxxx> wrote in
message news:e5XvVv0vIHA.552@xxxxxx

> sputnik wrote:
>

>> I have a vbscript that check the entire AD for a specific computer name,
>> and then the script deletes the computer name.
>>
>> What security measures can I put in place so Domain Controllers or member
>> servers are not deleted ?
>>
>> I am a little concerned here !

>
> Your script can check the operatingSystem attribute to make sure the
> string "server" is not found. I would make the check case insensitive (by
> using LCase for example).

Who will be running this script? If it is workstation administrators, then
I'd strongly suggest limiting the their ability to delete computer objects
to workstations, and specifically not allow them to delete servers of any
type. Ideally, the ability to delete domain controllers would belong only to
domain admins; for member servers this might be expanded somewhat, or left
at domain admins only.

/Al

Al Dunbar wrote:

> "Richard Mueller [MVP]" <rlmueller-nospam@xxxxxx> wrote in
> message news:e5XvVv0vIHA.552@xxxxxx

>> sputnik wrote:
>>

>>> I have a vbscript that check the entire AD for a specific computer name,
>>> and then the script deletes the computer name.
>>>
>>> What security measures can I put in place so Domain Controllers or member
>>> servers are not deleted ?
>>>
>>> I am a little concerned here !

>> Your script can check the operatingSystem attribute to make sure the
>> string "server" is not found. I would make the check case insensitive (by
>> using LCase for example).

>
> Who will be running this script? If it is workstation administrators, then
> I'd strongly suggest limiting the their ability to delete computer objects
> to workstations, and specifically not allow them to delete servers of any
> type. Ideally, the ability to delete domain controllers would belong only to
> domain admins; for member servers this might be expanded somewhat, or left
> at domain admins only.
>
> /Al
>
>

This script will be run by our workstation/desktop admins.

Out of interest any specific way of doing this that you had in mind. I
plan to use 2 methods for taking care of this. If you can add ideas
that would be great.

1. I delegate control to manage workstations on the OU level and will
omit the Domain Controllers OU from any delegating rules/policies. All
OU's where there is a possibility for workstations that require
managememnt will be delegated as mentioned.

2. And as a second measure the script can ommit deleteion of objects
within the Domain Controllers OU.

This may be an issue if we start placing domain controllers in other
containers scattered through AD.

How would you limit ability to delete computer objects only as oposed to
domain controllers ?

Cheers,

"sputnik" <sputnik@xxxxxx> wrote in message
news:egYJX8AwIHA.576@xxxxxx

> Al Dunbar wrote:

>> "Richard Mueller [MVP]" <rlmueller-nospam@xxxxxx> wrote in
>> message news:e5XvVv0vIHA.552@xxxxxx

>>> sputnik wrote:
>>>
>>>> I have a vbscript that check the entire AD for a specific computer
>>>> name, and then the script deletes the computer name.
>>>>
>>>> What security measures can I put in place so Domain Controllers or
>>>> member servers are not deleted ?
>>>>
>>>> I am a little concerned here !
>>> Your script can check the operatingSystem attribute to make sure the
>>> string "server" is not found. I would make the check case insensitive
>>> (by using LCase for example).

>>
>> Who will be running this script? If it is workstation administrators,
>> then I'd strongly suggest limiting the their ability to delete computer
>> objects to workstations, and specifically not allow them to delete
>> servers of any type. Ideally, the ability to delete domain controllers
>> would belong only to domain admins; for member servers this might be
>> expanded somewhat, or left at domain admins only.
>>
>> /Al
>>
>>

>
> This script will be run by our workstation/desktop admins.
>
> Out of interest any specific way of doing this that you had in mind. I
> plan to use 2 methods for taking care of this. If you can add ideas that
> would be great.
>
> 1. I delegate control to manage workstations on the OU level and will omit
> the Domain Controllers OU from any delegating rules/policies. All OU's
> where there is a possibility for workstations that require managememnt
> will be delegated as mentioned.
>
> 2. And as a second measure the script can ommit deleteion of objects
> within the Domain Controllers OU.
>
> This may be an issue if we start placing domain controllers in other
> containers scattered through AD.
>
> How would you limit ability to delete computer objects only as oposed to
> domain controllers ?
>
> Cheers,
>

Best is to use ACL's on the Domain Controllers OU, etc, so people don't have
permission to delete. There are ways to find DC's and servers, but given
just the machine name the best way I know of to make sure it is not a DC or
server is to make sure the string "server" is not found in the value of the
operatingSystem attribute of the computer object. All DC's and member
servers will have a Server OS.

Given the NetBIOS name of the computer, you can use the NameTranslate object
to get the Distinguished Name. This allows you to bind to the object. You
can then retrieve the Parent DN and check if that is the Domain Controllers
OU. However, I would expect member servers to be anywhere. You may still
need to use NameTranslate, but once you bind to the object the
operatingSystem attribute is easiest. If you connect to the computer
remotely with WMI you can retrieve the Role from the Win32_ComputerSystem
class, but this is more work and requires that the machine be up and
accessible.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Richard Mueller [MVP] wrote:

> "sputnik" <sputnik@xxxxxx> wrote in message
> news:egYJX8AwIHA.576@xxxxxx

>> Al Dunbar wrote:

>>> "Richard Mueller [MVP]" <rlmueller-nospam@xxxxxx> wrote in
>>> message news:e5XvVv0vIHA.552@xxxxxx
>>>> sputnik wrote:
>>>>
>>>>> I have a vbscript that check the entire AD for a specific computer
>>>>> name, and then the script deletes the computer name.
>>>>>
>>>>> What security measures can I put in place so Domain Controllers or
>>>>> member servers are not deleted ?
>>>>>
>>>>> I am a little concerned here !
>>>> Your script can check the operatingSystem attribute to make sure the
>>>> string "server" is not found. I would make the check case insensitive
>>>> (by using LCase for example).
>>> Who will be running this script? If it is workstation administrators,
>>> then I'd strongly suggest limiting the their ability to delete computer
>>> objects to workstations, and specifically not allow them to delete
>>> servers of any type. Ideally, the ability to delete domain controllers
>>> would belong only to domain admins; for member servers this might be
>>> expanded somewhat, or left at domain admins only.
>>>
>>> /Al
>>>
>>>

>> This script will be run by our workstation/desktop admins.
>>
>> Out of interest any specific way of doing this that you had in mind. I
>> plan to use 2 methods for taking care of this. If you can add ideas that
>> would be great.
>>
>> 1. I delegate control to manage workstations on the OU level and will omit
>> the Domain Controllers OU from any delegating rules/policies. All OU's
>> where there is a possibility for workstations that require managememnt
>> will be delegated as mentioned.
>>
>> 2. And as a second measure the script can ommit deleteion of objects
>> within the Domain Controllers OU.
>>
>> This may be an issue if we start placing domain controllers in other
>> containers scattered through AD.
>>
>> How would you limit ability to delete computer objects only as oposed to
>> domain controllers ?
>>
>> Cheers,
>>

>
> Best is to use ACL's on the Domain Controllers OU, etc, so people don't have
> permission to delete. There are ways to find DC's and servers, but given
> just the machine name the best way I know of to make sure it is not a DC or
> server is to make sure the string "server" is not found in the value of the
> operatingSystem attribute of the computer object. All DC's and member
> servers will have a Server OS.
>
> Given the NetBIOS name of the computer, you can use the NameTranslate object
> to get the Distinguished Name. This allows you to bind to the object. You
> can then retrieve the Parent DN and check if that is the Domain Controllers
> OU. However, I would expect member servers to be anywhere. You may still
> need to use NameTranslate, but once you bind to the object the
> operatingSystem attribute is easiest. If you connect to the computer
> remotely with WMI you can retrieve the Role from the Win32_ComputerSystem
> class, but this is more work and requires that the machine be up and
> accessible.
>

Connecting to the server is not real issue. I have used an ldap get
object and get attribute in OperatingSystem.

Your right it says something like Windows Server 2003.

Do I need to regular expression to get the server part out ?

"sputnik" <sputnik@xxxxxx> wrote in message
news:uVmD%23lBwIHA.4736@xxxxxx

> Richard Mueller [MVP] wrote:

>> "sputnik" <sputnik@xxxxxx> wrote in message
>> news:egYJX8AwIHA.576@xxxxxx

>>> Al Dunbar wrote:
>>>> "Richard Mueller [MVP]" <rlmueller-nospam@xxxxxx> wrote
>>>> in message news:e5XvVv0vIHA.552@xxxxxx
>>>>> sputnik wrote:
>>>>>
>>>>>> I have a vbscript that check the entire AD for a specific computer
>>>>>> name, and then the script deletes the computer name.
>>>>>>
>>>>>> What security measures can I put in place so Domain Controllers or
>>>>>> member servers are not deleted ?
>>>>>>
>>>>>> I am a little concerned here !
>>>>> Your script can check the operatingSystem attribute to make sure the
>>>>> string "server" is not found. I would make the check case insensitive
>>>>> (by using LCase for example).
>>>> Who will be running this script? If it is workstation administrators,
>>>> then I'd strongly suggest limiting the their ability to delete computer
>>>> objects to workstations, and specifically not allow them to delete
>>>> servers of any type. Ideally, the ability to delete domain controllers
>>>> would belong only to domain admins; for member servers this might be
>>>> expanded somewhat, or left at domain admins only.
>>>>
>>>> /Al
>>>>
>>>>
>>> This script will be run by our workstation/desktop admins.
>>>
>>> Out of interest any specific way of doing this that you had in mind. I
>>> plan to use 2 methods for taking care of this. If you can add ideas
>>> that would be great.
>>>
>>> 1. I delegate control to manage workstations on the OU level and will
>>> omit the Domain Controllers OU from any delegating rules/policies. All
>>> OU's where there is a possibility for workstations that require
>>> managememnt will be delegated as mentioned.
>>>
>>> 2. And as a second measure the script can ommit deleteion of objects
>>> within the Domain Controllers OU.
>>>
>>> This may be an issue if we start placing domain controllers in other
>>> containers scattered through AD.
>>>
>>> How would you limit ability to delete computer objects only as oposed to
>>> domain controllers ?
>>>
>>> Cheers,
>>>

>>
>> Best is to use ACL's on the Domain Controllers OU, etc, so people don't
>> have permission to delete. There are ways to find DC's and servers, but
>> given just the machine name the best way I know of to make sure it is not
>> a DC or server is to make sure the string "server" is not found in the
>> value of the operatingSystem attribute of the computer object. All DC's
>> and member servers will have a Server OS.
>>
>> Given the NetBIOS name of the computer, you can use the NameTranslate
>> object to get the Distinguished Name. This allows you to bind to the
>> object. You can then retrieve the Parent DN and check if that is the
>> Domain Controllers OU. However, I would expect member servers to be
>> anywhere. You may still need to use NameTranslate, but once you bind to
>> the object the operatingSystem attribute is easiest. If you connect to
>> the computer remotely with WMI you can retrieve the Role from the
>> Win32_ComputerSystem class, but this is more work and requires that the
>> machine be up and accessible.
>>

>
>
>
> Connecting to the server is not real issue. I have used an ldap get
> object and get attribute in OperatingSystem.
>
> Your right it says something like Windows Server 2003.
>
> Do I need to regular expression to get the server part out ?
>
>
>

I use the InStr function to search for substrings in a string. For example:

strOS = objComputer.operatingSystem
If (InStr(LCase(strOS), "server") > 0) Then
' Server operating system.
Else
' Non-server operating system.
End If

The InStr function returns the character position where the string first
appears, or 0 if it does not appear. The InStr function can also be made
case-insensitive with the optional parameter vbTextCompare. In that case you
must also specify the optional "start" parameter as the first parameter. For
example:

strOS = objComputer.operatingSystem
If (InStr(1, strOS, "server", vbTextCompare) > 0) Then
' Server operating system.
Else
' Non-server operating system.
End If

I believe you can also use regular expressions, but I have no experience
with that.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

I've used your script, with only one line diff...

strOS = objComputer.Get("OperatingSystem")

Full script below:





Set objComputer = GetObject ("LDAP://" & strComputerDN )
strOS = objComputer.Get("OperatingSystem")

If IsNull(strOS) Then
Wscript.Echo "Null Object"
End If


If (InStr(LCase(strOS), "server") > 0) Then
Wscript.Echo "Server operating system"

Else

Wscript.Echo "Non Server operating system"


Works a treat ! I have added an IsNull statement because I have some
computers which have not populated the OperatingSystem attribute. They
have just been created as computer objects manually in AD and no
computer has ever been associated to the object. When you double click
on them all fields are empty.

The script reports "The directory property cannot be found in cache"

the isNull function does not pick it up. I wnat to catch it to avoid
the error. Any ideas ?

"sputnik" <sputnik@xxxxxx> wrote in message
news:efZ1npMwIHA.1936@xxxxxx

> I've used your script, with only one line diff...
>
> strOS = objComputer.Get("OperatingSystem")
>
> Full script below:
>
>
>
>
>
> Set objComputer = GetObject ("LDAP://" & strComputerDN )
> strOS = objComputer.Get("OperatingSystem")
>
> If IsNull(strOS) Then
> Wscript.Echo "Null Object"
> End If
>
>
> If (InStr(LCase(strOS), "server") > 0) Then
> Wscript.Echo "Server operating system"
>
> Else
>
> Wscript.Echo "Non Server operating system"
>
>
> Works a treat ! I have added an IsNull statement because I have some
> computers which have not populated the OperatingSystem attribute. They
> have just been created as computer objects manually in AD and no computer
> has ever been associated to the object. When you double click on them all
> fields are empty.
>
> The script reports "The directory property cannot be found in cache"
>
> the isNull function does not pick it up. I wnat to catch it to avoid the
> error. Any ideas ?
>

I also have several manually created computer objects (for Win9x clients so
I can place them in groups for connecting printers in logon scripts). If you
use:

strOS = objComuter.operatingSystem

the variable strOS will be assigned an empty string if the attribute does
not have a value. The Get method raises an error in the same situation. The
only solutions I know of are:

1. Use the dot notation to retrieve the value if the attribute might not
have a value.
2. Trap the error that can be raised by the Get method. For example:
========
Set objComputer = GetObject ("LDAP://" & strComputerDN )
On Error Resume Next
strOS = objComputer.Get("OperatingSystem")
If (Err.Number <> 0) Then
On Error GoTo 0
strOS = "<no value>"
End If
On Error GoTo 0
========
I like to restore normal error handling as soon as possible so I can
troubleshoot if I mess up later.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

"sputnik" <sputnik@xxxxxx> wrote in message
news:egYJX8AwIHA.576@xxxxxx

> Al Dunbar wrote:

>> "Richard Mueller [MVP]" <rlmueller-nospam@xxxxxx> wrote in
>> message news:e5XvVv0vIHA.552@xxxxxx

>>> sputnik wrote:
>>>
>>>> I have a vbscript that check the entire AD for a specific computer
>>>> name, and then the script deletes the computer name.
>>>>
>>>> What security measures can I put in place so Domain Controllers or
>>>> member servers are not deleted ?
>>>>
>>>> I am a little concerned here !
>>> Your script can check the operatingSystem attribute to make sure the
>>> string "server" is not found. I would make the check case insensitive
>>> (by using LCase for example).

>>
>> Who will be running this script? If it is workstation administrators,
>> then I'd strongly suggest limiting the their ability to delete computer
>> objects to workstations, and specifically not allow them to delete
>> servers of any type. Ideally, the ability to delete domain controllers
>> would belong only to domain admins; for member servers this might be
>> expanded somewhat, or left at domain admins only.
>>
>> /Al
>>
>>

>
> This script will be run by our workstation/desktop admins.
>
> Out of interest any specific way of doing this that you had in mind. I
> plan to use 2 methods for taking care of this. If you can add ideas that
> would be great.
>
> 1. I delegate control to manage workstations on the OU level and will omit
> the Domain Controllers OU from any delegating rules/policies. All OU's
> where there is a possibility for workstations that require managememnt
> will be delegated as mentioned.

That is what we do, and seems the best solution to me.

> 2. And as a second measure the script can ommit deleteion of objects
> within the Domain Controllers OU.

That only prevents the script from being used to delete domain controllers;
it does nothing to prevent deletion through ADU&C, other scripts, or even a
copy of the script modified to allow deletion of any computer object.

> This may be an issue if we start placing domain controllers in other
> containers scattered through AD.

If your AD organization consists of container scattered all over, then you
will likely have other issues in the area of standardizing administrative
access in a manageable way.

> How would you limit ability to delete computer objects only as oposed to
> domain controllers ?

I would recommend an OU configuration that limits the ability of individuals
to, for example, delete computer objects to only those individuals
authorized to do so.

/Al