Nagios3 with Active Directory authorization on SLES10
Posted on Monday, 14th July, 2008 in Life
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 dependant 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:
<VirtualHost *:80> ## mod_core DocumentRoot "/usr/share/nagios" ServerName nagios.barfoo.org ServerAlias nagios3.barfoo.org ServerAdmin nagiosadmin@barfoo.org ## mod_rewrite RewriteEngine On RewriteRule ^/(.*) https://nagios.barfoo.org/$1 [L,R] </VirtualHost> <VirtualHost *:443> ## mod_core DocumentRoot "/usr/share/nagios" ServerName nagios.barfoo.org ServerAdmin nagiosadmin@barfoo.org ScriptAlias /nagios/cgi-bin /usr/lib/nagios/cgi Alias /nagios /usr/share/nagios Alias /pnp /usr/share/nagios/html/pnp4nagios <DirectoryMatch "/usr/(share/nagios|lib/nagios/cgi)"> AllowOverride None Order deny,allow Deny from all Allow from 10.0.0. Options None # Authorization AuthType Basic AuthName "Nagios Barfoo" # The authentification provider is mod_ldap AuthBasicProvider ldap # mod_ldap is our *only* authentification provider for this! AuthzLDAPAuthoritative on # Redirect the userfile requests to /dev/null AuthUserFile /dev/null # AD requires an authentication DN to access any records AuthLDAPBindDN "BARFOO\\ldap_nagios" AuthLDAPBindPassword "somethingrandom" # The URL to search in AuthLDAPURL "ldap://dc0.barfoo.org dc1.barfoo.org dc2.barfoo.org dc3.barfoo.org/OU=Users,dc=barfoo,dc=org?sAMAccountName?sub?(objectClass=*)" # Search the group membership in the specified group, otherwise it's gonna # get searched at the binding DN's location AuthLDAPGroupAttributeIsDN on Require ldap-group CN=gr_nagios,OU=Groups,DC=barfoo,DC=org </DirectoryMatch> ## mod_log ErrorLog /var/log/apache2/nagios.barfoo.org.error_log TransferLog /var/log/apache2/nagios.barfoo.org.access_log CustomLog /var/log/apache2/nagios.barfoo.org.ssl_request_log ssl_combined ## mod_ssl SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/apache2/ssl.crt/nagios.barfoo.org.crt SSLCertificateKeyFile /etc/apache2/ssl.key/nagios.barfoo.org.key <Files ~ "\.(cgi|shtml|phtml|php3|php?)$"> SSLOptions +StdEnvVars </Files> SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </VirtualHost>
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 extranous 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
Posted on Sunday, 29th June, 2008 in Life
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:
- dav_svn (dav_svn needs dav, thus the need to add it too)
- dav
- authnz_ldap (authnz_ldap needs ldap, so again we need that too!)
- ldap
After that, we can add our repository (or our multi-repository folder) to /etc/apache2/conf.d/subversion.conf:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | <IfModule mod_dav_svn.c> <Location /svn> DAV svn SVNParentPath /srv/svn # Limit write permission to list of valid users. <LimitExcept GET PROPFIND OPTIONS REPORT> # Require SSL connection for password protection. # SSLRequireSSL AuthType Basic AuthName "Subversion repositories (Domänenzugangsdaten)" # The authentification provider is mod_ldap AuthBasicProvider ldap # mod_ldap is our *only* authentification provider for this! AuthzLDAPAuthoritative on # AD requires an authentication DN to access any records AuthLDAPBindDN "CN=LDAP Subversion,OU=anon_accounts,OU=Users,DC=foobar,DC=org" AuthLDAPBindPassword "somethingrandom" # The URL to search in AuthLDAPURL "ldap://dc0.foobar.org/ou=Users,dc=foobar,dc=org?sAMAccountName?sub?(objectClass=*)" # Search the group membership in the specified group, otherwise it's gonna # get searched at the binding DN's location AuthLDAPGroupAttributeIsDN on Require ldap-group CN=gr_subversion,OU=Groups,DC=foobar,DC=org </LimitExcept> </Location> |
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:
[warn] [client 10.0.0.148] [9486] auth_ldap authenticate: user foo authentication failed; URI /svn/admin-scripts/!svn/act/71f2b65f-d050-0410-b33c-3b31fbb94a00 [ldap_search_ext_s() for use r failed][Operations error]
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 tommorow, today I’m gonna watch Band of Brothers.
Windows XP Embedded, Windows Server 2003 and GPO settings (the solution)
Posted on Wednesday, 4th June, 2008 in Life
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_USER\Software\Policies, 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!