This is going to be rather long, but let's do it anyway. First of all, yes this can be done. I can't supply much in the way of configuring CVS, but I can provide all you need to make a linux server authenticate users against Active Directory.
It all starts with /etc/nsswitch.conf. Here is the relevant section:
passwd: files ldap compat
shadow: files ldap compat
group: files ldap compat
Now, depending on what distro you are using, you will need to install some ldap packages. Under Redhat/Fedora/CentOS this would be nss_ldap, under Debian/Ubuntu and the likes, you will need libnss-ldap and libpam-ldap. I would also recommend some ldap-utils for debugging.
With the above your name services will attempt to use LDAP, so now you need to configure the various LDAP packages to use your AD server. The search base should be base cn=Users,dc=aminocom,dc=com and the bind DN should be binddn cn=LDAPsearch,cn=Users,dc=aminocom,dc=com. You will need to define a specific User to allow browsing of the AD. We have created a user named LDAPSearch, and put its credentials into a separate file named .secret. Read the documentation of these packages for more detail. Furthermore I would recommend a soft bind policy and the following attribute mappings:
# Services for UNIX 3.5 mappings
nss_base_passwd cn=Users,dc=aminocom,dc=com?sub
nss_base_shadow cn=Users,dc=aminocom,dc=com?sub
nss_base_group cn=Users,dc=aminocom,dc=com?sub
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute loginShell msSFU30LoginShell
nss_map_attribute gecos name
nss_map_attribute userPassword msSFU30Password
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_objectclass posixGroup Group
nss_map_attribute uniqueMember msSFU30PosixMember
nss_map_attribute cn cn
pam_login_attribute sAMAccountName
pam_filter objectclass=user
pam_member_attribute msSFU30PosixMember
pam_groupdn cn=nixUsers,cn=Users,dc=aminocom,dc=com
pam_password ad
All of this assumes that you have the Windows Services for Unix installed on your domain controller. In AD you will need to configure a primary Unix group (in our case called nixUsers) and add every CVS user into that group.
You should probably be able to use AD directly (i.e. without the Windows Services for Unix), but that will require different attribute mappings. You might have to experiment a bit there.
Now we get to the PAM configuration. Under Debian there are basically 4 files that need modifications:
1.) common-account:
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid
2.) common-auth:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >=500 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
3.) common-session:
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so
4.) common-password
password sufficient pam_unix.so md5 shadow nullok try_first_pass
password sufficient pam_ldap.so
password required pam_deny.so
Under Redhat (and derivatives) all the necessary changes should go into the relevant sections in /etc/pam.d/system-auth and /etc/pam.d/system-auth-ac.
The above will allow users to log in with AD credentials. However, this does NOT automatically create a home directory for them (unless you do some more scripting around that) and it does not allow them to change their passwords through linux. This can be done, too, but it requires modification of their workstations (if they use Linux). Any more questions re the above, just ask.
We use this on many of our servers, works like a charm.
Disclaimer: You probably shouldn't try to require_membership_of for root. Is there ever a case where root should not be able to login? You risk not being able to repair this machine without rebooting into single mode if something goes wrong (like its network going down).
I'll answer anyway.
TL;DR: If you want to enforce membership even for local users (root included), replace the first sufficient with a requisite.
require_membership_of is only used in pam_winbind.c in pam_sm_chauthtok (involved in the management group password) and pam_sm_authenticate (involved in the management group auth).
So if a user does not have the membership you require, the PAM step that will fail looks like:
auth [...] pam_winbind.so [...]
You do have one, but it's marked as sufficient:
auth sufficient pam_winbind.so
So if it fails, PAM will keep going through its chain. Next stop:
auth sufficient pam_unix.so nullok try_first_pass
This one will succeed, if getent passwd root returns a valid user, getent shadow root (ran as root) returns a valid encrypted password, and the password entered by the user matches.
I won't walk you through the rest, but nothing else will prevent root from logging in.
I would refer you to pam.d(5) for more information about the general PAM configuration mechanism, pam_unix(8) & co for the various modules.
Best Answer
My coworker resolved this. The issue was that we had old data in the winbind cache. We cleared the cache at /var/lib/samba and /var/cache/samba then restarted winbind and everything is working again.