Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a mixed Linux/Windows software development environment where the Linux clients are migrating to a system where they are able to authenticate against Active Directory. (That part I figured out)

Our lab is currently using CVS to conduct version control on our source code. In the migration, we will need users to be able to authenticate to our CVS server. I have it planned such that when the migration occurs, we will set up the CVS server to also authenticate users against AD.

Unfortunately, I do not have a lot of experience with CVS. Is this task even possible? From what I understand, it can be set up to authenticate users based on the local users on the system. However, since the actual users won't have their credentials stored locally on the server (as it's pulling them from AD), is it possible to point CVS to rely upon pam for authentication?

I have read about accessing CVS over SSH with user credentials. Would that be a requirement for this to occur? If so, how does one set this up?

I greatly appreciate the assistance!

share|improve this question

2 Answers 2

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.

share|improve this answer
up vote 0 down vote accepted

As it turns out, CVS just uses PAM. So, if your server is already configured to authenticate to AD, CVS will also receive the authentication info.

wolfgangsz's suggestion is very helpful in getting the 1st step completed (server authentication to AD via LDAP [you could also use Winbind]).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.