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:

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

Reply via email to