Login  | |
|
 |
Adding Members to a Security group in AD - 8/24/2005 12:37:13 AM
|
|
 |
|
| |
rbreakall
Posts: 4
Score: 0
Joined: 8/23/2005
From: Kentucky, USA
Status: offline
|
Greetings!
I have a vbscript that will add a machine to a security group. However, I need to run this under the context of a specific userid and password that has rights to do that on the production domain. I cannot seem to find any documentation on getobject or anything else where I can specify both a username and password. Am I overlooking something easy or can this not be done? The script will run as part of an installation, adding itself to a security group and then there will be gpos linked to that particular security group.
Here is my code...
Option Explicit
On Error Resume Next
'Set Target DC
Const sDomainController = "XXXXXX"
'Set SQL Params
Const sSQLServer = "OOOOOOOO"
Const sSQLDatabase = "TTTTTTTT"
Const sSQLTable = "UUUUUUUUU"
'Set group names and how many
Dim aSecurityGroup(1)
aSecurityGroup(1) = "NAC: MY SECURITY GROUP"
'Set OU to enumerated object to check/add
Const sTargetOU = "ou=Configure,ou=Managed Clients,DC=xxxxxxx,DC=xx,DC=xx"
Const sTargetGroup = "ou=SMS Package Deployment,DC=xxxxxxx,DC=xx,DC=xx"
Const ADS_PROPERTY_APPEND = 3
'Add Groups to objects
Call AddGroups
'Pause for anyone looking...
WScript.Echo
WScript.Echo "** Script Complete **"
WScript.Sleep 10000
'Done
WScript.Quit
' ^*^*^*^*^*^* Beginning of the Subs & Functions ^*^*^*^*^*^*
'===============================================================
'Enumerate, Check for membership, add if needed in designated OU
'===============================================================
Sub AddGroups()
Dim oLDAPConnection, oLDAPCommand, oLDAPRecordset
Dim sMoveOU
Const ADS_SCOPE_SUBTREE = 2
Set oLDAPConnection = CreateObject("ADODB.Connection")
Set oLDAPCommand = CreateObject("ADODB.Command")
Set oLDAPRecordset = CreateObject("ADODB.Recordset")
oLDAPConnection.Provider = "ADsDSOObject"
oLDAPConnection.Open "Active Directory Provider"
With oLDAPCommand
Set .ActiveConnection = oLDAPConnection
.CommandText = "Select Name, OperatingSystem from 'LDAP://" & sDomainController & _
"/" & _
sTargetOU & _
"' where objectClass='computer'"
.Properties("Page Size") = 1000
.Properties("Timeout") = 30
.Properties("Searchscope") = ADS_SCOPE_SUBTREE
.Properties("Cache Results") = False
Set oLDAPRecordset = .Execute
End With 'oCOMMAND
With oLDAPRecordset
.MoveFirst
Do Until .EOF
If Left(.Fields("Name").Value, 2) = "PC" Then
'WScript.Echo .Fields("Name").Value
Call AddMembership("cn=" & .Fields("Name").Value & "," & _
sTargetOU, .Fields("Name").Value)
End If
.MoveNext
Loop
End With 'oRecordset
oLDAPConnection.Close
End Sub
'===============================================================
' Add supplied targetobject to defined security groups
'===============================================================
Sub AddMembership(sTargetObject, sComputerName)
Dim iCount
Dim oGroup
'Loop through all defined groups
WScript.Echo sComputerName
For iCount = 1 To UBound(aSecurityGroup)
Set oGroup = GetObject("LDAP://cn=" & aSecurityGroup(iCount) & "," & sTargetGroup)
oGroup.PutEx ADS_PROPERTY_APPEND, "member", Array(sTargetObject)
Err.Clear 'Prepare for error trap if object is already member
On Error Resume Next
oGroup.SetInfo 'Set the group
Select Case Err.Number
Case -2147019886 'This error means object is already a member
On Error GoTo 0
'WScript.Echo sComputerName & " is already a member of " & aSecurityGroup(iCount)
Case Else 'Object added as member to supplied group
On Error GoTo 0
Call SQLLogging(sSQLServer, sSQLDatabase, sSQLTable, _
"AddSecurityGroup", "Info", "Added Group - " & aSecurityGroup(iCount), sComputerName)
End Select
Next 'iCount
Set oGroup = Nothing
End Sub
'=========================================================
' Log the activity in SQL
'=========================================================
Public Sub SQLLogging(sSQLServer, _
sSQLDatabase, sSQLTable, _
sSQLSource, sSQLSeverity, _
sSQLOperation, sSQLDescription)
Dim oSQLDatabase
'Create ADO Connection
Set oSQLDatabase = CreateObject("ADODB.Connection")
'Show what we are logging
WScript.Echo sSQLOperation & " - " & sSQLDescription
With oSQLDatabase
.ConnectionString = "Driver={SQL Server};Server=" & sSQLServer & ";Database=" & _
sSQLDatabase & ";Trusted_Connection=yes;"
.Open
.Execute "INSERT INTO " & sSQLTable & " (Source, Severity, Operation, Description, Recorded, DC) VALUES ('" & _
sSQLSource & "', '" & sSQLSeverity & "', '" & sSQLOperation & "', '" & sSQLDescription & "', '" & _
Date & " " & Time & "', '" & sDomainController & "')"
.Close
End With 'oSQLDatabase
Set oSQLDatabase = Nothing
End Sub
_____________________________
Programming is like making a fine wine, you must pay attention to every detail...
|
|
| |
|
|
|
|
RE: Adding Members to a Security group in AD - 8/24/2005 11:47:26 PM
|
|
|
|
| |
Country73
Posts: 733
Score: 10
Joined: 8/25/2004
From: USA
Status: offline
|
I haven't had the need to write a script to use the RUNAS command yet, but I did find this post about it.
Just let us know if this works out for you; just incase someone else needs to do the same thing.
RUNAS Script
|
|
| |
|
|
|
|
RE: Adding Members to a Security group in AD - 8/29/2005 11:38:04 PM
|
|
|
|
| |
rbreakall
Posts: 4
Score: 0
Joined: 8/23/2005
From: Kentucky, USA
Status: offline
|
That would definitely solve the problem. However, I got a snippet of code from someone where you can connect to the domain with alternative credentials and it appears to be a good way to handle it.
Just like the script you provided though, you need to run screnc to encode the script. Thanks for the help. Oh, btw, here's the snippet of code I was given, in case it will help out someone else.
Taken from:
http://www.microsoft.com/technet/scriptcenter/resources/qanda/dec04/hey1213.mspx
------
Hey, WW. In answer to your question, yes, both WMI and ADSI provide a way for you to run a script under alternate security credentials; that is, both allow you to specify a user name and a password under which the script will run. Furthermore, both of these technologies provide a way to ensure that this user name and password are encrypted, and are not passed across the network using clear text. Thanks for the question, and hope that helped.
Hey, just kidding! Most likely what you really want to know is how to run a script under alternate security credentials. Lets start by taking a look at a WMI script that connects to a remote computer (atl-ws-01) and retrieves the name of the operating system installed on that computer. Furthermore, it does this by running under the Administrator account, which in this example has a password of 4rTGh2#1:
Const WbemAuthenticationLevelPktPrivacy = 6
strComputer = "atl-ws-01"
strNamespace = "root\cimv2"
strUser = "Administrator"
strPassword = "4rTGh2#1"
Set objWbemLocator = CreateObject("WbemScripting.SWbemLocator")
Set objWMIService = objwbemLocator.ConnectServer _
(strComputer, strNamespace, strUser, strPassword)
objWMIService.Security_.authenticationLevel = WbemAuthenticationLevelPktPrivacy
Set colItems = objWMIService.ExecQuery _
("Select * From Win32_OperatingSystem")
For Each objItem in ColItems
Wscript.Echo strComputer & ": " & objItem.Caption
Next
As you can see, we start by creating a constant named WbemAuthenticationLevelPktPrivacy and assigning it the value 6; this value will be used to encrypt the communication between our computer and the remote computer. We then define four variables strComputer, strNamespace, strUser, and strPassword which hold the name of our remote computer; the WMI namespace we want to connect to; the user account we want to run the script under; and the password for that user account.
At this point were ready to connect to the remote computer using these alternate credentials. Thats what these lines of code do:
Set objWbemLocator = CreateObject("WbemScripting.SWbemLocator")
Set objWMIService = objwbemLocator.ConnectServer _
(strComputer, strNamespace, strUser, strPassword)
objWMIService.Security_.authenticationLevel = WbemAuthenticationLevelPktPrivacy
We begin by creating an instance of the SWbemLocator object, and then calling the ConnectServer method. ConnectServer gets passed four parameters, which just happen to correspond to the four variables we created a moment ago. We then set the Security_authenticationLevel property to WbemAuthenticationLevelPktPrivacy, giving us a more secure connection between the two computers.
From that point on, the rest of the code is the same old WMI code you know and love.
One important note: this approach, in which you run a script under alternate credentials, works only on remote machines. For some reason, WMI wont let you run a script under alternate credentials on your own computer. Go figure.
Now lets take a look at the ADSI version of this script. This sample script binds to the Ken Myer user account in Active Directory and tells us whether or not this account is disabled. The script connects to Active Directory using the fabrikam\Administrator, which has a password of 4rTGh2#1:
Const ADS_SECURE_AUTHENTICATION = 1
Const ADS_USE_ENCRYPTION = 2
strPath = "LDAP://cn=kenmyer,ou=Finance,dc=fabrikam,dc=com"
strUser = "fabrikam\Administrator"
strPassword = "4rTGh2#1"
Set objDSO = GetObject("LDAP:")
Set objUser = objDSO.OpenDSObject _
(strPath, strUser, strPassword, _
ADS_USE_ENCRYPTION OR ADS_SECURE_AUTHENTICATION)
Wscript.Echo objUser.AccountDisabled
In this script, we create two constants (ADS_SECURE_AUTHENTICATION and ADS_USE_ENCRYPTION) to ensure that the information passed between our computer and the domain is encrypted. We then create three variables strPath, strUser, and strPassword which host the ADsPath to the object we want to bind to in Active Directory (in this case, the Ken Myer user account); the account name we want to use when connecting to Active Directory; and the password for that account.
Next we bind to the LDAP provider; we start here because the LDAP provider accepts anonymous bindings. Having connected to the LDAP object, we can then call the OpenDSObject method to bind to the Ken Myer user account. Note that we must pass OpenDSObject four parameters: the ADsPath to the Active Directory object; the user name we want to use when connecting to Active Directory; the password for that account; and the two constants we defined earlier. As with WMI, as soon as we make the connection, the rest of the script is the same as any other ADSI script.
By the way, OpenDSObject also works with local user accounts; the primary difference is that you bind to WinNT provider instead of the LDAP provider (and, of course, the ADsPath will be different). Here are the relevant lines of code from a script that connects to a local computer:
strComputer = "WinNT://atl-ws-01"
strUser = "Administrator"
strPassword = "4rTGh2#1"
Set objDSO = GetObject("WinNT:")
Set objComputer = objDSO.OpenDSObject _
(strComputer, strUser, strPassword, _
ADS_SECURE_AUTHENTICATION OR ADS_USE_ENCRYPTION)
One thing we should add is that we dont recommend you hardcode passwords (especially Administrator passwords) in your scripts. Instead, you should make allowances to enter the password as a command-line argument or via an Input box or whatever works best for you.
_____________________________
Programming is like making a fine wine, you must pay attention to every detail...
|
|
| |
|
|
|
| |
|
|
 |
|
 |
|
|
Printable Version
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread