Quoting Jordan Brown <jordan.br...@oracle.com>:
Michael Anderson wrote:
So, this means that the entries are being found in the directory,
but for some reason aren't being or can't be used for mapping - is
that correct?
get-namemap and set-namemap operate on the "real" data stored on the
Domain Controllers, while normal mapping operations operate get their
information from a subset stored on the Global Catalog servers. My
guess is that the attributes were not being propagated to the GC.
I believe that the problem is that msSFU30Name isn't exported to the
Global Catalog, and the directory-based name mapping stuff requires
that the data be visible in the Global Catalog.
Here's an article that says how to make an attribute visible in the
Global Catalog:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;248717
Hmm, I tried that, but it didn't seem to help.
It might take a while for the GC to get updated. I don't know how that
mechanism works, but I believe they are separate databases and so I
doubt that changing the setting for an attribute has immediate effect.
I'm wondering if I should extend the AD schema as described in the
CIFS docs. Although it would seem redundant, since the desired data
is already in the SFU extensions.
I would hope that you could use the existing fields.
Note that you might be able to use sAMAccountName, which is already
propagated to the GC. sAMAccountName is shown in the UI as
"Pre-Windows 2000 logon name", and I believe is always a copy of the
msSFU30Name.
Thanks for all the assistance. Very helpful.
Sorry I can't be more definitive.
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?
BTW, I just noticed something in a previous message:
svccfg -s svc:/system/idmap setprop
config/ds_name_mapping_enabled=boolean: true
svccfg -s svc:/system/idmap setprop
config/ad_unixuser_attr=astring:msSFU30Name
svccfg -s svc:/system/idmap setprop
config/ad_unixuser_attr=astring: msSFU30GidNumber
First, I assume that the last command should be setting
ad_unixgroup_attr, not ad_unixuser_attr. I assume that's simply a
transcription error, since your experiments seem to work.
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.
This is how idmapd is configured:
# svccfg -s idmap listprop
config application
config/list_size_limit count 0
config/stability astring Unstable
config/value_authorization astring solaris.smf.value.idmap
config/machine_sid astring
S-1-5-21-1373536303-522864990-3864964639
config/ds_name_mapping_enabled boolean true
config/ad_unixname_attr astring msSFU30Name
config/ad_unixgroup_attr astring msSFU30GidNumber
config/domain_name astring elego.de
rpcbind dependency
rpcbind/entities fmri svc:/network/rpc/bind
rpcbind/grouping astring require_all
rpcbind/restart_on astring restart
rpcbind/type astring service
filesystem-minimal dependency
filesystem-minimal/entities fmri svc:/system/filesystem/minimal
filesystem-minimal/grouping astring require_all
filesystem-minimal/restart_on astring error
filesystem-minimal/type astring service
general framework
general/action_authorization astring solaris.smf.manage.idmap
general/entity_stability astring Unstable
general/single_instance boolean true
general/value_authorization astring solaris.smf.manage.idmap
start method
start/exec astring /usr/lib/idmapd
start/timeout_seconds count 60
start/type astring method
stop method
stop/exec astring :kill
stop/timeout_seconds count 60
stop/type astring method
refresh method
refresh/exec astring ":kill -HUP"
refresh/timeout_seconds count 60
refresh/type astring method
tm_common_name template
tm_common_name/C ustring "Native Identity Mapping Service"
tm_man_idmapd template
tm_man_idmapd/manpath astring /usr/share/man
tm_man_idmapd/section astring 1M
tm_man_idmapd/title astring idmapd
tm_man_idmap template
tm_man_idmap/manpath astring /usr/share/man
tm_man_idmap/section astring 1M
tm_man_idmap/title astring idmap
Second, setting ad_unixgroup_attr to msSFU30GidNumber will *not* work.
This mechanism needs an attribute that contains a group *name*, not a
group *number*. Of course it would be easy to allow it to accept
either, but it doesn't currently.
That doesn't explain your problems with mapping vuser1, though.
--
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
