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)'
|
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.
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.
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
