Active Directory authentification for Samba on SLES11

I recently “redesigned” the PXE-installation server, which comes with a Samba service to easily move files on/off the box. The old one had the restriction, you need to create local user accounts. Since I also did an distribution upgrade, I wanted to try the integration of SLES11 into Active Directory.

And as it turns out, it really is simple. Just follow the steps outlined in the handbook.

  1. Open the Windows Domain Membership module, yast samba-client (or yast, then Network Services -> Windows Domain Membership) and enter your Domain information
  2. Open the Samba Server Module, yast samba-server (or yast, then Network Services -> Samba Server) and also enter your Domain information

Just make sure, you also check the box labeled Also Use SMB Information for Linux Authentication, otherwise it won’t work — don’t ask me why …

Nagios3 with Active Directory authorization on SLES10

Well, it seems to be getting a “trend” for me, to integrate stuff into our Active Directory. Now that I know why, and how easy that is, I expect to add more stuff. The good thing about the integration is, that you only need to maintain a single source for authorization.

The bad thing about that is, that stuff becomes dependent on the Active Directory (we do have four domain controllers, so that should be fine).

Now, here’s the ssl-(only) apache2 configuration file for my vhost:

As you can see, AuthLDAPUrl holds the four LDAP servers separated by spaces (that’s what the Apache2 documentation says about that), and that actually works.

The only additional thing I had to change from the nagios part is in /etc/nagios/cgi.cfg to allow everyone to issue system commands. Also, if you ever stumble upon extraneous chars in the check_nrpe output, update to a newer NRPE version, that fixed it for me (that is on the receiver side – as in the box running the NRPE agent).

subversion on WebDAV with Active Directory authorization on SLES10

Okay, so I ended up toying with subversion via WebDAV on SLES today (I know, I know .. it’s bloody Sunday). It wasn’t much of a hassle though, after reading this. Sure, I made a few errors at first (simply confused the logic behind “Location” and “Directory“), but after that plain subversion commits via WebDAV (thus utilizing Apache) worked fine.

For POC or as a hint to myself, here’s where and what I needed to add/change:

Add the following modules to APACHE_MODULES in /etc/sysconfig/apache2:

  1. dav_svn (dav_svn needs dav, thus the need to add it too)
  2. dav
  3. authnz_ldap (authnz_ldap needs ldap, so again we need that too!)
  4. ldap

After that, we can add our repository (or our multi-repository folder) to /etc/apache2/conf.d/subversion.conf:

Now, as you can see, my goal was to not rely on a separate authorization database, but to use our already existing Active Directory at work. Generally this works just fine, but it didn’t. I tried various things, like trying another user, changing the group (as in the “require ldap-group“) as well as changing my own password. Zip.

All I got was this line in the error_log of Apache:

Now, that itself does tell you what is happening, but not why. So again, I ended up googling till I found this:

The suggested step was to add “REFERRALS off” to /etc/ldap/ldap.conf. Surprise, the file don’t exist. Heck, there’s that one in /etc/ldap.conf. I did that, still zip.

Did I get the wrong file ? Absolutely.

/etc/ldap.conf is used by nsswitch and pam_ldap, but not by openldap2 (which is what Apache is using). So reading this comment, adding the line to /etc/openldap2/ldap.conf, and *kaching*! Works.

Now I just need to install redmine (already installed ruby, rubygems and rubygem-rails from the SDK Addon), but I’ll leave that for tomorrow, today I’m gonna watch Band of Brothers.

Windows XP Embedded, Windows Server 2003 and GPO settings (the solution)

OK, so about an hour (yeah, yeah; I know .. I shouldn’t be working at that time, but it really gave me sleepless nights) ago, I finally figured out why the hell both my Windows XP Embedded thin clients as well as my Windows Server 2003 systems where showing this real *weird* behaviour when applying group policies, or more precise the user based configuration of a group policy.

The inspiration came to me after reading this and taking a look at regedit myself, where I noticed the entry “Permissions” for the first time ever since I’m using regedit. I also noticed, that the regedit permissions seem to be using the same groups, one would assign to NTFS resources.

That said, it really all boils down to the ntuser.dat (which *IS* HKEY_CURRENT_USER). As I created the profile with a different user than I am using it with (basically, I want ~12.000 users to use this one profile), I needed to change the permissions *INSIDE* regedit to include a group containing all these users. After that, any user could again merge the settings from ntuser.pol into HKEY_CURRENT_USERSoftwarePolicies, which in return gives you the joy of your fucking policies working again.

TADAAAAAA! About two weeks worth of work spent for such a shitty thing, and noticing it when you’re off work — priceless!

Windows XP Embedded and GPO settings (continued)

Well, as I said in my previous post, I do have some weird things happening. Apparently adding the domain user to the local group “Administrators” makes everything just works fine, yet he can’t do administrator like stuff (like turning off the write protection, changing local user accounts, …).

Also, if you’re looking for a smart way of how to add a certain global group (as in Active Directory group) to a local group, try this:

That simple, doesn’t even need the usual credentials to lookup the object, it apparently bypassed that step *shrug*.

And yet another weird thing is: if I run a certain command from a deployment script, it gives me different result as a manual execution of said script would give me .. *shrug*

If I put that into a rsp (that is Wyse Device Manager script), it ain’t working. Would I be executing it myself without the WDM, everything works like a charm … *yuck*

Windows XP Embedded and GPO settings

We’re currently having a weird issue (which we had before); the Windows XP Embedded powering our Wyse V90’s isn’t applying any GPO settings if you log on with a user that has a configured profile.

Googling (is that a valid word yet ?!) for it, only resulted in one useful link, which is apparently a guy with the exact same problem … *shrug* I’m completely out of ideas by now, as I don’t even have a place to start (as in where the reason might be located).

Well, I do have a place to start with (that’s the local Events Viewer), which indeed lists some errors, but only such errors which ain’t making any sense. For example I see this:

  • Userenv:1086 – “Windows cannot do loopback processing for downlevel or local users. Loopback processing will be disabled.
  • SceCli:1704 – “Security policy in the Group policy objects has been applied successfully.
  • Userenv:1085 – “The Group Policy client-side extension Folder Redirection failed to execute. Please look for any errors reported earlier by that extension.

VBscript & Active Directory and printers ? (continued)

As I posted earlier, I tried working around some limitations in Microsoft’s Active Directory by teaching the script some intelligence.

But, since we recently started using Thin Clients, all the stuff I did with the fancy vbs was just a waste-of-time. Turns out, Windows XP Embedded doesn’t work quite the same as a “normal” Windows XP (that’s where I tested the script on), and it simply dies when running the WMI Query. Bollocks.

So I switched back, utilizing a shortcut in Startup, but pointing to the shortened vbs (see below) instead of the ugly batch file someone wrote.

But even that doesn’t work all the time, I still have to figure out why.