AD Authentication with RHEL 6

We’ve been using AD authentication with our RHEL and CENTOS 4 and 5 systems for some time, now, so I was anxious to see what kinds of changes might have come up with RHEL6. Not much, happily, but there was one change that took a little while to figure out. We’ll run through all the steps, from beginning to end, here.

How to Delegate Services control in Windows

Microsoft offers a very helpful document here and here detailing how to use subinacl to give control over a service to a user. Unfortunately, they’ve not updated that article in quite some time, and it’s now out of date: beginning with Windows Server 2003 SP1, authenticated users no longer can enumerate services.
While that’s a good thing, it renders the solution presented by Microsoft only partially complete.
So we’ll correct that, going through all the steps that are necessary to give an (otherwise) unprivileged user permissions to control any given services through the services control panel. This will work on Windows Server through v2008 R2.

Linux error id: cannot find name for user ID xxxxx when using Domain Authentication

We recently had a problem, after re-doing some samba configurations on RHEL 5, in which a user would log in (successfully), but then be presented with the follow errors:

id: cannot find name for user ID 10001
id: cannot find name for group ID 10000
id: cannot find name for user ID 10001

Of course, none of our domain ACLs worked for this user, either, which was a real problem. Finally, after running through the more obvious problems (communication with domain controllers: verified with wbinfo; uid and gid allocation and linking: set explicitly with wbinfo; winbind cache (cleared, both in /var/cache/samba and /var/lib/samba); date/time discrepancies; domain membership), we found the culprit: file permissions.

NT_STATUS_PIPE_DISCONNECTED with Samba Winbind and Windows Server 2008 R2 Domain Controller

We recently upgraded our domain controllers to Windows Server 2008 R2, and our RHEL 5 authentication through our Windows domain immediately broke.
Here was the error:

[2010/06/21 09:32:57, 0] rpc_client/cli_pipe.c:rpc_api_pipe(790) rpc_api_pipe: Remote machine adserver.my.edu pipe \NETLOGON fnum 0x8007returned critical error. Error was NT_STATUS_PIPE_DISCONNECTED

A little searching online shows a lot of people with this or related problems, but the solutions appear to be many, and there mostly isn’t a solution posited.
But there is this: https://bugzilla.redhat.com/show_bug.cgi?id=561325
In short: there's a bug in the samba package that prevents it from working with Windows Server 2008 R2 domains. If you’re running into this problem, the solution is to remove your existing samba installation and install, instead, the samba3x packages.
Note that samba3x was a "technology preview" from RedHat, which means that it offered little support for it. This has changed, and it's now a supported package in RHEL 5.

yum erase samba samba-common
yum install samba3x samba3x-client

You’ll have to re-do your configuration, so it might be worthwhile to back up your /etc/samba/smb.conf file.

Active Directory (AD) Authentication on a Linux Server

Domain Authentication for Linux

I've updated the instructions here to support RHEL 6. I've streamlined things a bit, too, so I'd head over to this page to get the latest on setting up AD authentication for a Linux server. There are a lot of how-tos surrounding the integration of authentication and authorization in Linux through Active Directory domains. I've found a variety of them helpful, and I've found more to be confusing, rather than helpful. Here I'm hoping to put together a start-to-finish process for using your domain to authenticate and authorize users on your linux box. These instructions are written for Red Hat Enterprise Linux v5 (RHEL from now on). That means the file locations should be the same for CENTOS distros (which I highly recommend as a server OS), but that they might move around a bit for others.

A very small bit of background: this system uses winbind and smb to connect to the domain to authenticate users. Kerberos is used to join the system to the domain. The benefit of this system is that it's secure and it's pretty easy to configure. Coupled with PAM (Pluggable Authentication Modules), it's quite flexible, and it's really pretty cool functionality.

LDAP Authentication in Mediawiki

LDAP Authentication in Mediawiki isn't terribly hard, and it's so very worth it. This post shows how one implementation succeeded, and hopefully it'll help with yours. I have to say that I'm a little hesitant to post this entry, as many people have done so, and inevitably, the post becomes dated, full of deprecated and even downright wrong information. So one runs the risk in the end of being more of a hindrance than a help. So: caveat emptor. I decided in the end to write this because it took a very long time to implement this very useful extension to MediaWiki, and I hope my process will help others in their own implementation. Having said that, one really should check out all of the work Ryan Lane has done and continues to do in writing and supporting this excellent extension. The main page for the extension can be found here. These instructions were written as we implemented version 1.1g, which is one release behind the (as of this writing) current version of 1.2a. Having got that behind us, I hope this is helpful to you:

LDAP Authentication

This is a big one. It can be got from the MediaWiki Extensions Site. The instructions are pretty tough to follow, but it does work.
Here are our settings in LocalSettings.php, in which the user is authenticated against the domain, and all users except those in a select group are disallowed from logging in.

A note about SSL encryption

SSL encryption is necessary to ensure this is a secure process. Especially given that we're talking about domain usernames and passwords. So first, make sure that the apache server is requiring https when accessing the wiki. Second, for the SSL piece of the LDAP authentication to work, the wiki server has to recognize and trust the root CA of the LDAP server (or, in our case, the LDAP virtual IP fronted by a netscaler device). I hope to have instructions on doing this piece posted soon. In any case, please do this before going further.

LocalSettings.php Contents

#LDAP authentication require_once( "$IP/extensions/LdapAuthentication.php" );
#$wgLDAPDebug = 6;
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "DOMAINNAME");
$wgLDAPServerNames = array( "DOMAINNAME"=>"ldapserver.FQDN" );
$wgLDAPSearchStrings = array( "domainname"=>"DOMAINNAME\\USER-NAME" );
$wgLDAPEncryptionType = array( "domainname"=>"ssl" );
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;
$wgLDAPBaseDNs = array( "domainname"=>"dc=tcu,dc=edu" );
$wgLDAPSearchAttributes = array( "domainname"=>"sAMAccountName" );
 #Everything above is for simple LDAP authentication; the stuff below is for group syncronization
#DNs in $wgLDAPRequiredGroups must be lowercase, as search result attribute values are...
$wgLDAPRequiredGroups = array( "domainname"=>array("Fully qualified LDAP cn structure goes here") );
$wgLDAPGroupUseFullDN = array( "domainname"=>true );
$wgLDAPLowerCaseUsername = array( "domainname"=>true, );
$wgLDAPGroupObjectclass = array( "domainname"=>"group" );
$wgLDAPGroupAttribute = array( "domainname"=>"member" );
$wgLDAPGroupSearchNestedGroups = array( "domainname"=>true );
$wgLDAPUseLDAPGroups = array( "domainname"=>"true" );
$wgLDAPGroupNameAttribute = array( "domainname"=>"cn" );
 #Adding new groups to the list of possible groups. This value (the group name)
#also needs to be added to the user_groups table in the database. That happens manually.
$wgGroupPermissions['groupname']['edit']= true;

The first bit should be pretty self-explanatory: load the extension, then set the basic variables as specific to your environment. In the examples here, I have used "domainname" and "DOMAINNAME" instead of our true domain name. Case matters here, so stay sharp! Note that the $wgLDAPBaseDNs variable is important; it must be correct. In most cases, this is the final bit of your domain name. For instance, if my domain is example.com, my base DN is also example.com.
Likewise, $wgLDAPRequiredGroups is very specific, and if it's not just right, the whole thing will break. Note that ldapsearch--a piece of openssl--can be an extremely useful tool in determining the correct settings for all of this. If you're using linux, you very likely already will have this tool. If you're using Windows, dsget is an equivalent (as a part of Windows Server) that can really help you out of a jam. Many will recommend a web-base ldap browser, but, honestly, I think the command-line tools like ldapsearch and dsget are much easier to use and set up.
If you're having difficulty, uncomment the $wgLDAPDebug line, and it'll provide a lot of useful debugging information within the browser session.

User Rights Management

User rights management is done through groups. We use the domain groups for this purpose, but it's also necessary to tell MediaWiki about the groups, and how we'll use them. This is done in a single step:

Defining group rights

Edit the LocalSettings.php file and add lines as below:

## The following three lines disable anonymous access $wgGroupPermissions['*' ]['createaccount'] = false;
$wgGroupPermissions['*' ]['read'] = false;
$wgGroupPermissions['*' ]['edit'] = false;
$wgGroupPermissions['tcudba']['edit'] = true;
$wgGroupPermissions['user' ]['move'] = false;
$wgGroupPermissions['user' ]['read'] = true;
$wgGroupPermissions['user' ]['edit'] = false;
$wgGroupPermissions['user' ]['upload'] = false;

In the above example, the default group (user) only can read articles. Those who have not authenticated (*) cannot do anything in the wiki. Those in TCUDBA can edit documents.
There are a variety of possible permissions, which are detailed here. The table below shows a few of the more relevant permissions:

Permission	Description
read	allows viewing pages not defined in $wgWhitelistRead
edit	allows editing unprotected pages.
createpage	allows the creation of new pages (requires the edit right).
move	allows renaming page titles.
upload	allows the creation of new images and files.
createaccount	allows the creation of new user accounts.
delete	allows the deletion of edits and pages.

Modifying User Groups

An easy way to modify the Mediawiki database is to use PHPmyAdmin. Of course, whether you use a GUI or the command line, the data to modify is the same.
After logging in to phpmyadmin, select the WIKIDB database on the left. Then select the user_groups table and click on the browse button. You'll see the userid and group name of all the users. Note that the userid is a number; you have to use the users table to find out which userid corresponds to which username. Use this method to get back as a sysop in the wiki if you've accidentally removed yourself from that group. If you're still a sysop, you simply can use the special:userrights page.

Troubleshooting

If you receive the error basedn is not set for this type of entry, trying to get the default basedn, that means that the $wgLDAPBaseDNs variable isn't set correctly. At the time of this writing, the correct value for that is
$wgLDAPBaseDNs = array( "tcu"=>"dc=tcu,dc=edu" );
The following commands also can be helpful in determining if your system is set up correctly:

ldapsearch -x -D @TCU -W -b "dc=tcu,dc=edu" "sAMAccountName=" -H ldaps://ldap.example.com

openssl s_client -connect ldap.example.com:636