Ldap – Why can’t Get-ADObject -identity against a GC use the SamAccountname, given that this attribute is

active-directoryldap

Why can't Get-ADObject against a GC use the SamAccountname for the -identity parameter, given that this attribute is in the GC? The help for that cmdlet lists only DN and GUID as acceptable for -identity, and indeed only those work. But its just more common to need to query the GC on a list of logon names (SamAccountnames) that could be in any domain in the forest, which is my case here.

Is this a limitation of LDAP, the GC, the partial attribute set, or the PS cmdlets?

Best Answer

You probably want to use Get-ADUser if you're trying to get a list of user logon names, or Get-ADComputer if you're looking for systems which log on as well.

Or if you for some other reason need to use Get-ADObject, you can use a filter on SAMAccountNames instead: Get-ADObject -f {SAMAccountName -like "*searchfilter*"}

I'm not familiar with the design decisions behind why only certain attributes are valid. But, I would imagine that you cannot query against all AD Objects by SAMAccountName because most AD objects don't have a SAMAccountName.

Related Solutions

Ldap – Configuring OpenLDAP as a Active Directory Proxy

You need to add mappings to your slapd.conf file:

moduleload rwm
...
overlay rwm
rwm-map attribute uid sAMAccountName
rwm-map objectClass posixGroup group 
rwm-map objectClass posixAccount person
rwm-map objectClass memberUid member

Then you can search for the uid attribute instead of the sAMAccountName attribute in your .htaccess file:

AuthLDAPURL "ldap://breauthsrv01.xxx.de:389/OU=xxx,DC=int,DC=xxx,DC=de?uid?sub"

Powershell – How to use get-qadcomputer to return all computer objects that have msFVE-RecoveryInformation child objects

I don't believe that this is possible with only one LDAP search, regardless of what type of child object you are looking for. In cases like this I usually try to find if there is an attribute in either the parent or the child that references the other so that I can use that to retrieve the data I want, but in this case there doesn't seem to be.

What might be a better approach than invoking an LDAP search for each computer is this: 1. Use Get-QADObject to enumerate the msFVE-RecoveryInformation objects in your environment, starting from as low of a search root as possible. 2. Build a list of DNs for the parent computer objects using the data retrieved from those objects and store those DNs in an array. 3. Either call Get-QADComputer and use Where-Object to filter out the computers without a DN matching those stored in your array or if there are not many computers that are bitlocker enabled, call Get-QADComputer for each DN in your array to get the computer objects.

FYI, I did a quick Google search for "BitLocker cmdlets" to see if there was an easier way and it returned a go.microsoft.com link to a "Future Resource" document for Windows Server 2008 R2, so maybe these are coming at some point. All that document says for now though is "The document you are attempting to access is not yet available."

Best Answer

Related Solutions

Ldap – Configuring OpenLDAP as a Active Directory Proxy

Powershell – How to use get-qadcomputer to return all computer objects that have msFVE-RecoveryInformation child objects

Related Topic