ADSI ldap connection

[ghigginson]

I need to read specific AD object attributes for the user running a powershell script. This will be run by all users as part of a login script. Although its easy to connect to AD using ADSI and LDAP, to read the users attributes I need the fully qualified distinguished name, which I won't know.

Is there any way of connecting to the object of a user who is running a script to get access to the attributes? I don't want to use directory.searcher as this will be run every time a user logs in so searching will cause a lot of load on AD.

Thanks

[ghigginson]

I need to read specific AD object attributes for the user running a powershell script. This will be run by all users as part of a login script. Although its easy to connect to AD using ADSI and LDAP, to read the users attributes I need the fully qualified distinguished name, which I won't know.

Is there any way of connecting to the object of a user who is running a script to get access to the attributes? I don't want to use directory.searcher as this will be run every time a user logs in so searching will cause a lot of load on AD.

Thanks

[donj]

What's the final disposition for this information? Maybe there's another approach that will accomplish what you need...

[jvierra]

Sorry - I am retracting this until I can find the right copy of the code example.

There is a thread in the forum with this as part of a discussion including a number of examples on how to use this with PoSH.

I will try and find the code before the end of this afternoon.
jvierra2008-04-07 10:05:05

[jvierra]

I found the dmissing code file. I also simplified it to just this one case and wrapped as a function for convenience. The code in the function runs stand-alone also.
This function makes one call to AD and searches using an indexed item. It is as fast as anything that can access AD. I don't expect anything but a root reference would be any faster.

Code: Select all

	
function Get-CurrentUser{
     $searcher=New-Object DirectoryServices.DirectorySearcher
     $searcher.Filter="(&(objectcategory=person)(objectclass=user)(sAMAccountname=$env:username))"
     $searcher.FindOne()
}
	

[jvierra]

For completeness - as a one-liner.

Code: Select all

	
((New-Object DirectoryServices.DirectorySearcher "(&(objectcategory=person)(objectclass=user)(sAMAccountname=$env:username))").FindOne()).GetDirectoryEntry()
	

[jvierra]

A little clarification might help her.

The NET 2.0 "DirectorySearcher" class is a logical inplementaion of the standard LDAP/COM/API search mechanisms for AD. As Don suggested above, searching on an indexed item does not cause a load on AD.

I ran the above in a loop and compared it to direct access using "ADSI" and the full DN of the user. The perf mon on the AD machine could not distinguish between the two accesses. They were all well within the "noise". Most AD accesses, even large queries" cause little trouble for AD. I suspect that amore sophisticated benchmark might find a subtle difference in the times although I bet they bot end up using the identical same execution path to retrieve the object expecially since it is already in memory.

The DirectorySearcher method is and has been teh acceepted method for doing this as long as I can remember so there shouldn't be any issues with it.

Yes - knowing the DN at login would be excellent for many reasons. Saving it to the environment in the login script might be helpfull at other times.

Be careful not to overload the environment too much. A large environment may have a negative impact on some legacy applications.

Here is a good method to directly retrieve the DN in PowerShell using a VBSCRIPT helper function.

vbs script file

Code: Select all

	
' FILE: GetDN.vbs
	
' display the distinguishedName of the current user
	
'  
	
Set a = CreateObject("ADSystemInfo")
WScript.Echo a.UserName
	

Call the above from PowerShell like this:

PS>$currentUserDN=.GetDN.vbs //NOLOGO
PS>[adsi]"LDAP://$currentUserDN"

This returns the DN into a string that is usable with ADSI. The file is assumed to be in the current folder. Nothing is written to or changed in the system. By applying the string to the "[adsi]" type creation we will retrieve the user object. Performance can actually be slower than using the searcher because we have to call an external subsystem (WSH) to get the DN.

If someone were to take the time to create a wrapper for "ActiveDS" COM library it could be used directly from PowerShell. Currently it has no type info either in the DLL or in a TLB file so it is not "discoverable" by PoSH.

Actually the performance difference, even on a slow machine, is not noticeable.