Quoting Jordan Brown <jordan.br...@oracle.com>:
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 is. A query on port 389 returns several other msSFU30
attributes in addition to those replicated in the GC.
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?
Yes.
I assume also that you have anonymized some of this output, replacing
your actual domain with "domain.com"?
Yes.
[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.
After setting up from scratch again, get-namemap works again. I would
attribute this analomy to some fat-fingered typing error of mine along
the way somewhere.
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".
Aha! After 'c)' above, things are looking better:
# idmap show -cv vus...@domain.com uid
winuser:vus...@domain.com -> uid:100029
Source: New
Method: AD Directory
DN: CN=vuser1,CN=Users,DC=domain,DC=com
Attribute: msSFU30Name=vuser1
# idmap show -cv vus...@domain.com unixuser
winuser:vus...@domain.com -> unixuser:vuser1
Source: New
Method: AD Directory
DN: CN=vuser1,CN=Users,DC=domain,DC=com
Attribute: msSFU30Name=vuser1
# idmap show -cv gvus...@domain.com gid
wingroup:gvus...@domain.com -> gid:11019
Source: New
Method: AD Directory
DN: CN=Gvuser1,CN=Users,DC=domain,DC=com
Attribute: msSFU30Name=Gvuser1
# idmap show -cv gvus...@domain.com unixgroup
wingroup:gvus...@domain.com -> unixgroup:Gvuser1
Source: New
Method: AD Directory
DN: CN=Gvuser1,CN=Users,DC=domain,DC=com
Attribute: msSFU30Name=Gvuser1
Now, when I am logged on to a windows domain member computer, the
files are presented with the correct owner and permissions. Yay!
Interesting:
when I copy a file from the CIFS share to the windows desktop, the
user's unix GID disappears from the permissions, and the 'SYSTEM'
group appears instead. If create a file on Windows, there exist
windows permissions for the user and SYSTEM, the unix group is
'nobody', and the unix owner is no longer owner, but a generic user
with certain ACL rights to the file and can read, write, but not
delete files. So the perms look like this on opensolaris:
# ls -vl created_on_windows.txt
----------+ 1 vuser1 2147524611 0 Mai 26 00:03
created_on_windows.txt
0:user:vuser1:read_data/write_data/append_data/read_xattr/write_xattr
/execute/delete_child/read_attributes/write_attributes/delete
/read_acl/write_acl/write_owner/synchronize:allow
1:group:2147483648:read_data/write_data/append_data/read_xattr
/write_xattr/execute/delete_child/read_attributes/write_attributes
/delete/read_acl/write_acl/write_owner/synchronize:allow
I suppose I have to walk the share with inheritable 'owner@'
permissions, or something like that?
But how do I make newly created files belong to the unix primary group?
Thanks again for all the help,
Michael
--
Michael Anderson
IT Services & Support
elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany
phone +49 30 23 45 86 96 michael.anderson at elegosoft.com
fax +49 30 23 45 86 95 http://www.elegosoft.com
Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
