A little while ago, I posted a question (now deleted) about why I couldn't make the ldapfetch query work with certain DNs.
It turns out I had more problems than that. After rechecking my queries, it turns out that ldapfetch isn't working for me at all. So I have most likely been troubleshooting the wrong problem for hours!
So now I'm stumped...
I have different groups of accounts for certain purposes, that have the same base name, but with differing prefixes.
Like: for accname1, accname2 we also have corresponding accounts other_accname1, other_accname2 etc
This query works fine, and will return the attributes of accname1:
| ldapsearch basedn="OU=Level3,OU=Level2,OU=Users,DC=domainname,DC=com" search="(&(objectClass=user)(!(objectClass=computer)))" attrs="sAMAccountName,distinguishedName"
| search sAMAccountName=accname1
If I add an ldapfetch here, to get attributes from the corresponding other_accname1, I get nothing back.
| ldapsearch basedn="OU=Level3,OU=Level2,OU=Users,DC=domainname,DC=com" search="(&(objectClass=user)(!(objectClass=computer)))" attrs="sAMAccountName,distinguishedName"
| search sAMAccountName=accname1
| ldapfetch dn="CN=other_accname1,OU=other,OU=something,DC=domainname,DC=com" attrs="displayName"
This will not add the field "displayName" to the results.
I tried running the example that came with the Splunk add-on, and this shows the same behaviour:
| ldapsearch search="(objectClass=organizationalUnit)" attrs="ou,description,gPLink,gPOptions"
| sort ou
| rex field=gPLink max_match=10 "\[LDAP://(?<gpo>[^;]+);\d+\]"
| makemv allowempty=true tokenizer="([^\n]+)" gpo
| ldapfetch dn=gpo attrs=displayName
| table ou,description,displayName
| rename ou as "Name", displayName as "Linked GPO"
I get nothing back from ldapfetch here either.
What am I doing wrong.....
We found the answer to this one eventually.
As usual, the answer is: because of my innate stupidity.
The problem lies with the DN fed to ldapfecth: The distinguishedName for the two objects do not match.
While the dN for "accname1" starts with "CN=accname1,OU=.....", the dN for "other_accname1" starts with somethigns completely different. Thus creating the dN from one based on the other is not possible this way.
We found the answer to this one eventually.
As usual, the answer is: because of my innate stupidity.
The problem lies with the DN fed to ldapfecth: The distinguishedName for the two objects do not match.
While the dN for "accname1" starts with "CN=accname1,OU=.....", the dN for "other_accname1" starts with somethigns completely different. Thus creating the dN from one based on the other is not possible this way.