Michael Anderson wrote:
Here's a query that may help to illuminate matters.  You have to run it
as root so that it can use your system's credentials.  This is roughly
the query that the mapping code uses; if it doesn't retrieve the
appropriate attributes then mapping isn't going to work.

|# ldapsearch -R -h <yourGCserver> -p 3268 -s subtree -b '' -o
mech=gssapi -o authzid='' '(sAMAccountName=vuser1)'|

# exte.comd LDIF
# LDAPv3
# base <> with scope subtree
# filter: (sAMAccountName=vuser1)
# requesting: ALL

# vuser1, Users, domain.com
dn: CN=vuser1,CN=Users,DC=domain,DC.com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: vuser1
givenName: vuser1
distinguishedName: CN=vuser1,CN=Users,DC=domain,DC.com
instanceType: 4
whenCreated: 20091215103053.0Z
whenChanged: 20100510065727.0Z
displayName: vuser1
uSNCreated: 1122529
uSNChanged: 1352342
name: vuser1
objectGUID:: LtWX7JjtpUO3s3EVCIg1sg==
userAccountControl: 512
primaryGroupID: 513
sAMAccountName: vuser1
sAMAccountType: 805306368
userPrincipalName: vus...@domain.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC.com
msSFU30Name: vuser1
msSFU30UidNumber: 100029

So that's what that looks like. Should be enough, at least for uid resolution, or?

Is that the output from the ldapsearch command that I gave, or from some other tool? It is important, for instance, that the ldapsearch is connecting to port 3268 (the GC port) rather than to 389 (the DC/LDAP port).

Yes, it was a transcription error. But my experiments have stopped working. This was after I deleted /var/idmap/db and restarted idmapd. I also replicated msSFU30Name to the GC. Now I get:

# idmap get-namemap winuser:mand
Querying DNS for SRV RRs named '_ldap._tcp.dc._msdcs' for 'domain.com'
Found _ldap._tcp.dc._msdcs.domain.com 600 IN SRV [0][100] bdc2.domain.com:389
                No namemap found in AD.

Here you are looking at user mand, where you were previously looking at vuser1. I assume that's both have msSFU30Name populated?

I assume also that you have anonymized some of this output, replacing your actual domain with "domain.com"?


OK, I've done a bunch of experimentation and I may have some answers.

I can't immediately explain why get-namemap used to work for you and now doesn't.

I have found two bugs in directory-based name mapping that might, either alone or together, explain your problems.

6954913 Mapping to ephemeral followed by directory-based name mapping does not use directory data 6954902 mapping to unknown type does not use directory-based mapping information

6954913 makes it so that changes to the directory-based name mapping configuration and the directory data that it uses may not be picked up by the mapping process. Largely, once the configuration and directory data have been changed and the system rebooted, this shouldn't be a problem, however...

6954902 makes it so that an attempt to map a Windows identity to an unknown UNIX type will erroneously ignore directory-based mapping data, which can also trigger 6954913. This should be fairly rare, since mapping to an unknown UNIX type is used only rarely. The only two cases that I know of are certain SMB ACL operations and "idmap show" with no target type.

I'm working on both of those, but it will be a while before any change is available externally. In the meantime, you can work around most of the problems by:

1) After you make changes to the directory-based name mapping configuration, and after you make changes to the mapping data in the directory, clear the idmap cache. There are about four ways to do this:
   a)  "idmap flush -a" is the best answer, if you have a recent enough
        system that it's available.
   b) Reboot the system
   c) svcadm disable idmap, then rm /var/run/idmap/idmap.db,
      then svcadm enable idmap
   d) /lib/svc/bin/sqlite /var/run/idmap/idmap.db
       sqlite> delete from idmap_cache;
       sqlite> delete from name_cache;
       sqlite> ^D
   Please note that (a) is the long-term answer; the others rely on
   implementation details that are subject to change.
2) When you experiment with "idmap show", always specify a target type. That is, instead of saying "idmap show -c u...@example.com", say "idmap show -c u...@example.com uid" or "idmap show -c u...@example.com unixuser".

cifs-discuss mailing list

Reply via email to