A Script to Enable Trust for Delegation in Active Directory: To allow a user or computer account to impersonate another user, you must trust that account for delegation. This is necessary, for example, if a user hits a web site, and that web site must connect to another server, such as a SQL server or a file server, using the user's credentials. Normally, access to the other server would be denied, because the authentication request is coming from a different account (the service account that is running the web service). The web service is actually forging the user's signature in a sense. The account doing the impersonation must be trusted to do so. To manually trust an account for delegation, launch Active Directory Users and Computers. From the menu, select View - Advanced Features. Find the account, and click on the Delegation tab. Then select "Trust this account for Delegation" as shown in the figure. Note that the delegation tab will not show up for a user account, unless an SPN (service principal name) has been added to the account.
When you have a multi-tiered application, all of the computers and service accounts used for every tier except that back-end must be trusted for delegation. In other words, if you have a web server, an application server, and a database server, you must trust the web server, the web service account, the application server, and the application service account. If you have an application distributed across many servers, enabling them all can be a challenge. That's where this script comes in.
Some might have security concerns about a computer that is allowed to impersonate a user and connect to any service on any server. In that case you can configure constrained delegation, which allows the computer to impersonate the user when connecting to only the services and servers specified. To see how to configure constrained delegation with a Perl script, click here.
This script configures an account to be trusted for delegation. The script takes an argument (the user or computer name), it uses our familiar ADODB search code to find the account. Then it makes a change to the userAccountControl attribute of the account. This attribute is a bitmask, and each bit represents a different boolean account setting. We're changing the bit that enables/disables trust for delegation.
use Win32::OLE;
$TRUSTED_FOR_DELEGATION = 524288;
$account=@ARGV[0];
$base="<GC://".Win32::OLE->GetObject("LDAP://RootDSE")->Get("RootDomainNamingContext").">";
$connection = Win32::OLE->new("ADODB.Connection"); $connection->{Provider} = "ADsDSOObject"; $connection->Open("ADSI Provider"); $command=Win32::OLE->new("ADODB.Command"); $command->{ActiveConnection}=$connection; $command->{Properties}->{'Page Size'}=1000; $rs = Win32::OLE->new("ADODB.RecordSet");
$command->{CommandText}="$base;(cn=$account);distinguishedName;subtree"; $rs=$command->Execute;
if($rs->{recordCount} < 1){ print "Account not found\n"; }
until ($rs->EOF){ $dn=$rs->Fields(0)->{Value}; if($obj=Win32::OLE->GetObject("LDAP://$dn")){ $obj->{userAccountControl}=($obj->{userAccountControl} ¦ $TRUSTED_FOR_DELEGATION); $obj->SetInfo(); $error= Win32::OLE->LastError(); if($error == 0){ print uc($account)." trusted for delegation successfully\n"; }else{ print "Failed with error $error\n"; } }else{ print "Failed to connect to account\n"; } $rs->MoveNext; }
0 comments:
Post a Comment