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
objectSid:: AQUAAAAAAAUVAAAAlY9rWhrl0jyBPJSISQUAAA==
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"?
[later...]
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
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
