Questions[winbind](server)

I've setup a Samba 4 AD domain controller on Debian Jessie (samba 4.2.10). Everything's working fine, except that winbind gives wrong user/group information.

I have a sample user "testuser" and a security group "people". Their UNIX attributes are setup as follows:

Yet winbind shows this:

root@agnus:~# wbinfo -i testuser
testuser:*:10010:100:Test User:/home/HOME/testuser:/bin/false

The UID matches, but everything else is wrong.

My smb.conf contains this:

# Global parameters
[global]
        workgroup = HOME
        realm = HOME.LOCAL
        netbios name = AGNUS
        server role = active directory domain controller
        server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
        idmap_ldb:use rfc2307 = yes

        idmap config *:backend = tdb
        idmap config *:range = 2000-9999

        idmap config HOME:backend = ad
        idmap config HOME:schema_mode = rfc2307
        idmap config HOME:range = 10000-99999

        winbind nss info = rfc2307
        winbind enum users = yes
        winbind enum groups = yes
        winbind normalize names = yes
        winbind use default domain = yes
        winbind refresh tickets = yes

[netlogon]
        path = /var/lib/samba/sysvol/home.local/scripts
        read only = No

[sysvol]
        path = /var/lib/samba/sysvol
        read only = No

What's wrong with my setup?

How do Active Directory domain joined computers (native MS Windows or Linux with winbind) determine the closest password server? This question implies a cluster with 2+ Active Directory servers in different locations.

On Windows there is no apparent option for preference over which Active Directory server will be used to authenticate, etc.

On Linux (with samba/winbind) there is a setting for smb.cfg ("password server") but it is optional (when used in combination with setting "security = ads").

I'm taking the samba / winbind / PAM route to authenticate users on our linux servers from our Active Directory domain.

Everything works, but I want to limit what AD groups are allowed to authenticate. Winbind / PAM currently allows any enabled user account in the active directory, and pam_winbind.so doesn't seem to heed the require_membership_of=MYDOMAIN\\mygroup parameter. Doesn't matter if I set it in the /etc/pam.d/system-auth or /etc/security/pam_winbind.conf files.

How can I force winbind to honor the require_membership_of setting? Using CentOS 5.5 with up-to-date packages.

Update: turns out that PAM always allows root to pass through auth, by virtue of the fact that it's root. So as long as the account exists, root will pass auth. Any other account is subjected to the auth constraints.

Update 2: require_membership_of seems to be working, except for when the requesting user has the root uid. In that case, the login succeeds regardless of the require_membership_of setting. This is not an issue for any other account. How can I configure PAM to force the require_membership_of check even when the current user is root?

Current PAM config is below:

auth sufficient pam_winbind.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

account sufficient pam_winbind.so
account sufficient pam_localuser.so
account required pam_unix.so broken_shadow

password ..... (excluded for brevity)

session required pam_winbind.so
session required pam_mkhomedir.so skel=/etc/skel umask=0077
session required pam_limits.so
session required pam_unix.so

require_memebership_of is currently set in the /etc/security/pam_winbind.conf file, and is working (except for the root case outlined above).

I have some linux boxes that use Windows Active Directory authentication, that works just fine (Samba + Winbind).

What I would like to do now though is only allow certain people or certain groups to login using Active Directory credentials. Currently anyone with a valid AD account can login. I want to limit this to only a few groups. Is this doable?

We're looking at deploying SMB homes on Debian (5.0.3) for our mac clients rather than purchasing four new Xserves. We've got our test servers built and functioning properly. Windows clients behave perfectly, but we've run into an issue with OS X (10.6.x and 10.5.x). We're going this route instead of Windows file servers due to a whole bunch of other issues that arise when going that way.

Specifically, when mounting a SMB share with unix extensions switched on and the remote server bound to AD, the finder cannot save files on the share, instead touching the file and then bombing out with a -36 IO error, folder creation is fine. Copying files in the terminal behaves fine and the problem seems to be limited to the finder.

The issue arises (I think) as the remote UID/GID is passed across when using unix extensions. OS X uses its own winbind idmap (odsam) to work out the effective UID/GID from AD users and groups whilst we're using a rid map on the server. Consequently, there is a mismatch in ownership which the finder chooses to honour.

How OS X appears to handle this is to use the remote uid and gid at the file permission level (see below) and then set an OS X acl granting the local uid/gid to have the appropriate permissions on the file. I think the finder touches the file (which the kernel allows because of the ACL) and then checks the filesystem perms and drops out with the IO error.

On a Client

fc-003353-d:homes2 root# ls -led test/
drwx------+ 2 135978  100513  16384 Feb  3 15:14 test/
 0: user:jfrench allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit
 1: group:ARTS\domain users allow 
 2: group:everyone allow 
 3: group:owner allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit,only_inherit
 4: group:group allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit,only_inherit
 5: group:everyone allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit,only_inherit

We've tried the following without any luck:

• Setting the Linux side file owner to match the OS X GID/UID
• Adding ACLs on the linux filesystem which grant the OS X GID/UID perms
• Disabling extended attributes
• Setting steams=no in /etc/nsmb.conf on the client

We're currently running a workaround which is to just turn off unix extensions which forces the macs to just mount the share as the local user with u=rwx perms. This works for most things but is causing a few apps that expect certain perms to break in subtle ways. Worst case scenario is that we'll continue running in this way but we would like to have the unix extensions on.

Regards.

Relevant SMB config below:

[global]
        workgroup = ARTS
        realm = *snip*
        security = ADS
        password server = *snip*
        unix extensions = yes
        panic action = /usr/share/panic-action %d
        idmap backend = rid:ARTS=100000-10000000
        idmap uid = 100000-10000000
        idmap gid = 100000-10000000
        winbind enum users = Yes
        winbind enum groups = Yes
        veto files = /lost+found/aquota.*/
        hide files = /desktop.ini/$RECYCLE.BIN/.*/AppData/Library/
        ea support = yes
        store dos attributes = yes
        map system = no
        map archive = no
        map readonly = no