I've been able to get it to work with DOT7 mode but have't tried with 8. MS AD 2003R2 or above supports RFC2307bis attributes (although you can use other values for them, like I am using sAMAccountName instead of UID below).

Some of the required option are not shown by default which is odd but this works for me, I am using port 3268 because I have multiple domains, to support that you need to make sure your required attributes (UID,GID etc) are replicated to Global Catalogs (not all are by default) and have "ldap.site.company.com" resolve to a Global Catalog.
ldap.ADdomain                company.com
ldap.base                    dc=company,dc=com
ldap.base.group              dc=company,dc=com
ldap.base.netgroup
ldap.base.passwd             dc=company,dc=com
ldap.enable                  on
ldap.minimum_bind_level      simple
ldap.name                    cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=com
ldap.nssmap.attribute.gecos  gecos
ldap.nssmap.attribute.gidNumber gidNumber
ldap.nssmap.attribute.groupname cn
ldap.nssmap.attribute.homeDirectory UnixHomeDirectory
ldap.nssmap.attribute.loginShell loginShell
ldap.nssmap.attribute.memberNisNetgroup memberNisNetgroup
ldap.nssmap.attribute.memberUid memberUid
ldap.nssmap.attribute.netgroupname cn
ldap.nssmap.attribute.nisNetgroupTriple nisNetgroupTriple
ldap.nssmap.attribute.uid    sAMAccountName
ldap.nssmap.attribute.uidNumber uidNumber
ldap.nssmap.attribute.uniqueMember member
ldap.nssmap.attribute.userPassword unixUserPassword
ldap.nssmap.objectClass.groupOfUniqueNames group
ldap.nssmap.objectClass.nisNetgroup nisNetgroup
ldap.nssmap.objectClass.posixAccount user
ldap.nssmap.objectClass.posixGroup group
ldap.passwd                  ******
ldap.port                    3268
ldap.rfc2307bis.enable       on
ldap.servers                 ldap.site.company.com
ldap.servers.preferred
ldap.skip_cn_unescape.enable on
ldap.ssl.enable              off
ldap.timeout                 20
ldap.usermap.attribute.unixaccount sAMAccountName
ldap.usermap.attribute.windowsaccount sAMAccountName
ldap.usermap.base
ldap.usermap.enable          on

Jeremy Page | Senior Technical Architect | Gilbarco Veeder-Root, A Danaher Company
Office:336-547-5399 | Cell:336-601-7274 | 24x7 Emergency:336-430-8151
On 04/10/2014 12:51 PM, Michael Bergman wrote:
Randy Rue wrote:
The real filer that I'm trying to add this to has so far only been serving NFS/unix even though CIFS is enabled and it's added to our AD. But so far it's only serving NFSv2 with auth_sys. Now I’m trying to enable the extended_groups magic and I'm guessing I need to add enough AD capability for users to map between unix and AD accounts. And sure enough, the usermap.cfg file on both the real and simulated filers is the default.

To make the mapping actually happen (user mapping is fine, but where's your UNIX group info? Nowhere? In MS AD somehow?) you might need to actually CIFS share the data paths you have NFS exported.  I'm not sure, it could be enough to just have the CIFS service active and correctly configured in the vfiler in Q.

auth_sys is depending on UID & GID which come in inside the NFS packets. There's no translation or lookups anywhere taking place. It's the same for NFSv3 as v2, NFSv4 is different.  So in a basic setup, there's no NIS or MS AD lookups taking place for antyhing that has to do with File Level ACLs *provided* you have unix style security for your data (which you have).

So far so good.

Now you've done this:

nfs.authsys.extended_groups_ns.enable   on
nfs.max_num_aux_groups    64              (or whatever)

Suddenly everything changes. Now ONTAP has to look up the user corresponding to the UID in the NFS packet, in group. Either NIS group or in /etc/group in the machine (if all this works via /etc/nsswitch.conf, I'm not sure as I've never tried it.)

It will then replace all the GIDs it got in the NFS packet that came in, with what it found in group.  N.B. this includes the users primary GID :-(

I don't know if there's any connection to any MS AD "groups" in all this, if not then you can never get this to work the way you want.
user <-> user mappings in usermap.cfg fine, but if you don't have any UNIX users anyway, neither in NIS nor in /etc/passwd & /etc/group in the filer, there's not really anything for the mapping function to do

Regards,
/M

Added this to the usermap.cfg file:

NTDOM\* == *

Where NTDOM is our AD domain. This should map NTDOM\whoever to the unix whoever in both directions? Rebooted the simulator to make sure this took effect. Still no luck.

Another new clue, running “getXXbyYY getpwbyname_r whoever” at the shell on the filer returns “Could not get passwd entry for name = whoever.” Sure looks like the filer is not resolving AD accounts. And sure enough, if I run that command on the NFS-only filer that I’m trying to add extended_groups to, I get the same error. And if I run it on yet a different filer that’s running multiprotocol, the user resolves.

What step have I missed?

Randy in Sunny Seattle



_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters



Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.