Things I've found useful

This guy takes a computer with MSDOS 5.0 installed and then upgrades through every major version of Windows all the way up to Windows 7.

Related posts:

1. Dumb Windows Update message
2. The windows experience.
3. Disable Caps Lock in Windows

So after a few hours getting Linux authenticating happily from Active Directory, I turned my attention to getting it all working with encryption.

Initially I had tried a telnet to port 636 (the LDAPS port) which failed, so it didnt look like my AD box was talking LDAPS. Somewhere to start I guess!

Enabling LDAPS in AD

I followed this article to the letter, which lead me on a slightly convoluted path because I ended up making another 2003R2 server to act as a Certificate Server, before finally getting it all working. I called upon the excellent ldap.exe again which is handy to prove its all working using SSL.

LDAP command line tools

Before poking around with actually making authentication work, I wanted to make the useful command line tools, like ldapsearch work with an encrypted connection. This turned out to be remarkably simple. You just have to change ldap:// to ldaps:// and if you are working with self-signed certificates (as I am) you need to add TLS_REQCERT never to /etc/openldap.conf, meaning my file now looked like this:


URI ldap://adserver.112.riviera.org.uk
BASE dc=112,dc=riviera,dc=org,dc=uk
TLS_REQCERT never


With that done, running the following command ought to return the same set of data as it did before you enabled encryption, but this time if you use Wireshark or something similar you should see no unencrypted LDAP traffic.


ldapsearch -x -LLL -E pr=200/noprompt -D "bindaccount@112.riviera.org.uk" -w $PASSWORD -s sub "(cn=*)" cn mail sn


nss_ldap config

Lastly you’ll actually want to configure the /etc/ldap.conf file which the nss_ldap packages use, this is also very simple. First, you have a choice to make, do you want pre LDAPv3 style SSL with LDAP over the top or to you want to use LDAPv3 only TLS. The library supports both, and they both work fine against Windows 2003R2 AD. The ssl off entry in the config file needs to be changed to one of:

• ssl on – Use pre LDAPv3 SSL
• ssl start_tls – Use LDAPv3 and greater TLS

As I said, either work with AD, so which you choose is up to you, or any local security polcies

With that changed, I also needed to add in a second line, to disable rootCA certificate checking, because of my self-signed cert. With that change made as well, my final /etc/ldap.conf file looked like:


host 192.168.254.14
base dc=112,dc=riviera,dc=org,dc=uk
binddn bindaccount@112.riviera.org.uk
bindpw $BINDPASSWORD
scope sub

ssl start_tls
tls_checkpeer no

timelimit 10
bind_timelimit 10
idle_timelimit 3600
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
nss_base_passwd dc=112,dc=riviera,dc=org,dc=uk?sub
nss_base_shadow dc=112,dc=riviera,dc=org,dc=uk?sub
nss_base_group dc=112,dc=riviera,dc=org,dc=uk?sub?&(objectCategory=group)(gidnumber=*)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute gecos cn
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uniqueMember member


With this file changed, all your authentication traffic should now be running over an encrypted link. With a network sniffer, you can clearly see the differences between having ssl on and ssl start_tls set in the config file.

Hope that helps somebody, its the second time I’ve done this and last time I didnt write it down, hopefully next time I wont spend so long going over old ground!

Today I set out to get RHEL 5.x (Specifically 5.5) to authenticate from a Windows 2003 R2 Active Directory. I used plenty of web pages, none of which were 100% correct for my setup, so I thought I’d document exactly what I did here for my own future reference, if anybody else finds it useful, so much the better. To start with, thanks to the following pages, between them, they got me about 80% of the way there:

• Scott Lowe has a useful howto here. It is version 4 currently, click around his site to ensure he hasnt updated it before you use it as a reference.
• The second resource I used is here.

Required RPMs

You need a few packages installed, some of which are likely to be installed already, some not. The ones I have, with their versions are:

• nss_ldap-253-25.el5
• krb5-libs-1.6.1-36.el5_5.6
• openldap-2.3.43-12.el5_5.3
• ntp-4.2.2p1-9.el5.centos.2.1

I also found it useful to have openldap-clients-2.3.43-12.el5_5.3 installed as well, because that gives you ldapsearch, which is handy for debugging and testing things.

Names

In all of the following these names have been used:

• bindaccount – The name of the simple account inside AD for binding
• 112.riviera.org.uk – The DNS name of my domain
• ONEONETWO – The other (windows!?) name of my domain
• adserver.112.riviera.org.uk – the fqdn of my AD
• dc=112,dc=riviera,dc=org,dc=uk – My BaseDN, (I used the handy ldp.exe to find this, from this KB Article)

Active Directory

The blog post from Scott Lowe, explains about adding in the “Server for NIS” stuff into Windows, so I wont go into that here. Suffice to say, in any practical sense, you need it installed. One other thing to note is that the DNS service on the AD machines really likes to know about your new linux client. I created a A record with the associated PTR record for all the new Linux clients which were going to join the domain. Doing this before you start makes life easier later. I added a couple of test users into AD before starting to configure the Linux end too, the settings on ‘UNIX Attributes’ tab are shown below

Linux Setup

Before touching any config files make sure your client has its own IP and FQDN listed in /etc/hosts. Also make sure time is syncronised with AD, a default AD install puts a time server up for you, so you could use that, whatever you use, make sure they are in sync. The files I modified and what they ended up looking like are as follows, in all cases except for nsswitch.conf these are the entire files, so feel free to copy and paste and kill what is already there.

/etc/openldap/ldap.conf

This file configures the openldap clients, not strictly neccerssary, but useful to ensure you can talk ldap to your AD. Once this file is written you should be able to query AD with the following command

ldapsearch -x -LLL -E pr=200/noprompt -D "bindaccount@112.riviera.org.uk" -w $PASSWORD -s sub "(cn=*)" cn mail sn

I’ve put my password in a bash variable, just replace $PASSWORD with yours, if this fails then try the full command, which wont be using any defaults from /etc/openldap/ldap.conf:

ldapsearch -x -LLL -E pr=200/noprompt -h adserver.112.riviera.org.uk -D "bindaccount@112.riviera.org.uk" -w $PASSWORD -b "dc=112,dc=riviera,dc=org,dc=uk" -s sub "(cn=*)" cn mail sn

If that also fails you might want to try telneting to the LDAP port on the AD box, to see if that is open

My ldap.conf only has the following in it:


URI ldap://adserver.112.riviera.org.uk
BASE dc=112,dc=riviera,dc=org,dc=uk


/etc/krb5.conf


[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = 112.RIVIERA.ORG.UK
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes

[realms]
112.RIVIERA.ORG.UK = {
kdc = adserver.112.riviera.org.uk
admin_server = adserver.112.riviera.org.uk
default_domain = 112.riviera.org.uk
}

[domain_realm]
.112.riviera.org.uk = 112.RIVIERA.ORG.UK
112.riviera.org.uk = 112.RIVIERA.ORG.UK

[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}


/etc/ldap.conf


host 192.168.254.14
base dc=112,dc=riviera,dc=org,dc=uk
binddn bindaccount@112.riviera.org.uk
bindpw $BINDPASSWORD
scope sub
ssl no
timelimit 10
bind_timelimit 10
idle_timelimit 3600
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
nss_base_passwd dc=112,dc=riviera,dc=org,dc=uk?sub
nss_base_shadow dc=112,dc=riviera,dc=org,dc=uk?sub
nss_base_group dc=112,dc=riviera,dc=org,dc=uk?sub?&(objectCategory=group)(gidnumber=*)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute gecos cn
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uniqueMember member


/etc/pam.d/system-auth


#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
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_krb5.so use_first_pass
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_krb5.so use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so

session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022
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_krb5.so
session optional pam_ldap.so


/etc/nsswitch.conf

I have not included all of nsswitch.conf here because I only changed the following three lines. Simply add ldap after files for each.


passwd: files ldap
shadow: files ldap
group: files ldap


/etc/samba/smb.conf


workgroup = ONEONETWO
security = ads
realm = 112.riviera.org.uk
use kerberos keytab = true
password server = adserver.112.riviera.org.uk


Finished!

When all that is done and working you should be able to run ‘getent passwd ‘ and have it return your passwd file entry from AD. You should also be able to su to the user, and login via either console or SSH. If the users home directory isnt created, pam should create it for you.

Next on my list is to make all this work with encrypted LDAP.

After nearly 7 weeks without having to suffer Windows in any of its incarnations, I returned to work today and had the pleasure of XP on my horribly clunky Thinkpad. Very shortly after booting it I was presented with the following error message.

What a wonderful dialogue box and what a ‘Useful tip’. A Google search suggests it is something to do with the Windows Bluetooth stack. Oh I dont fucking care you stupid program, I just wanted to message somebody, you worked 7 weeks ago, why are you arsing around now.

As an aside, I notice the 8.3 filename, which still at some level seems to exist in Windows XP. How quaint of it!

Nice little reg hack to dsiable the Caps lock key in windows here.

Just needed to auth a Redhat (actually Centos) 4 update 4 machine from an Active Directory server, thought I ought to make a note for future reference
It is worth gathering some information before you start, you will need the follow:

AD Domain, in the example I use HILDEBRANDTECH
Domain Controllers, in the example i use win23kent.hildebrandtechnology.local
ADS Realm, mine was HILDEBRANDTECHNOLOGY.LOCAL

It seems that for all of this case is important. Thanks Microsoft.

Other things to watch for are:

1. Your client machine can resolve the hostname of your ad server, try with ping now and if it fails fix it before you start.
2. Check your clocks are in sync, kerberos uses time based tickets so any clock skew at all will cause problems.

Because I was using RedHat Enterprise I had the luxury of using the authconfig. Login as root or su and run authconfig from the command line, you will be presented with some options for where the machine should source user and authentication data from. You need to tick the ‘Use Winbind’ option in both columns, after making my selections mine looked like this:

After making the correct settings, hit next. On the next screen you need to enter all the information you gathered before starting. Additionally I chose /bin/bash as the template shell:

After typing all the above in hit Ok. You can choose ‘Join Domain’ at this point but I prefer to do that manually so you can ensure it was successful.

Once you are at your prompt again, run the following:

[root@adc-a04 ~]# net ads join -U administrator
administrator's password:
Using short domain name -- HILDEBRANDTECH
Joined 'ADC-A04' to realm 'HILDEBRANDTECHNOLOGY.LOCAL'
[root@adc-a04 ~]#

If you see a message similar to the above your machine should now be joined to the domain.

If you now run ‘getent passwd’ you should see some extra users are displayed, the ones gathered from the AD. An example of one is shown below.

HILDEBRANDTECH\robin:*:16777223:16777216:Robin Kearney:/home/HILDEBRANDTECH/robin:/bin/bash

You should now be able to login as ‘HILDEBRANDTECH\robin’. By default winbind requires the domain to be entered as part of the username. If your linux machine is only going to authenticate from a single AD realm you can make a small change to smb.conf to avoid this.

In /etc/samba/smb.conf look for the line which reads:

winbind use default domain = no

And change the no to yes. Then issue a ‘service winbind restart’ and re-run your ‘getent passwd’ you should notice the domain component of all the usernames has gone. Now you can simple use ‘robin’ to login.

Your users should now be able to login. There is a slight problem in that they will have no home accounts, pam can help with this though.

If you edit /etc/pam.d/login and add the following as the last line:

session required pam_mkhomedir.so skel=/etc/skel/ umask=0077

Pam will auto create the user a home account when they first login.

There is one minor issue with the default winbind settings for home accounts, by default winbind is configured set AD users’ home accounts to /home/DOMAIN/USER this is fine in our setup but pam refuses to create the DOMAIN directory, so none of the home accounts will get created.

You can fix this in one of two ways. First, manually create the /home/DOMAIN for each of your AD domains, this will likely be just the one. Or and this might suit better, change the structure of home accounts for AD users. This is done in /etc/samba/smb.conf. You need to add or edit a line like the following:

template homedir = /home/%U

The default here is %D/%U. %D gets expanded to the DOMAIN. The official samba documentation for this setting is here

Hopefully after all that you can still login, and your AD users can too.

This week I will be mainly fooling with VPN’s. First off is a PPTP server so the Windows 2k and XP laptops can connect. I’ve found this little daemon which seems to work perfectly well for XP, 2K machines and my Mac OS X (10.1.3) Powerbook and Imac.

The only fiddly bits with installing poptop is that you need a patched up version of pppd so that you can support all the of Microsoft extensions and force the link to be encrypted.

The first step in creating my pptp server was to install a recent patched up version of pppd, which I found here. Installing this is as easy as installing any other RPM and required no post installation fiddling.

Next up was to install the MPEE (Microsoft Point-to-Point Encryption) support, this comes as a set of kernel modules from the pptpclient project. Their documentation, and download page is here. I used this rpm, because our RedHat 9 machine had been patched up to the 2.4.20-20.9 kernel and is a SMP box.

The final bit of software needed to make all this work was the actually poptop binaries, I could not find a RPM for these so I had to install them from source. Rather than using their current (1.1.4-b4) beta I prefered to use the current stable release (1.1.3) which can be downloaded from here. When I install an application from source I always install the application in accordance to the OFA (Optimal Flexible Architecture) standard, more details of which can be found on Dannys site. Rather than just unpack the source and run ./configure && make && make install as root I use a couple of simple scripts, so that the compile is repeatable and at a later date I can tell exactly what options were used. Below is my Build script

gunzip -c pptpd-1.1.3-20030409.tar.gz | tar xvf -
cd poptop
./configure --prefix=/usr/local/app/poptop-1.1.3
make

and the Install script:

cd poptop
make install

Once poptop was installed I needed to write a couple of simple config files, the options and how all this fits together is documented very well on the poptop home page in their Documentation section, so I will not explain all the options here, but I will include my config files for reference:

/etc/pptpd.conf

speed 115200
option /etc/ppp/pptp-options
debug
localip 10.1.1.100-199
remoteip 10.1.2.100-199
listen 213.52.209.13
pidfile /var/run/pptpd.pid

/etc/ppp/pptp-options

debug
name pptp
domain install.mydomain
auth
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe
ms-dns 172.16.2.11

/etc/ppp/chap-secrets

myusername   pptp    mypassword   10.1.2.100

The final bit of the puzzle was to sort out a nice redhat style start stop script, I couldnt find an existing one so I’ve written one, which you can grab here.

After the daemon has been started its a simple matter of configuring your 2k/XP clients to connect. A nice tutorial of how to configure 2K can be found here.

One last note, if you are connecting to a machine which runs iptables or some similar firewall you will need to allow PPTP into the machine, we run a iptables firewall on our PPTP server, the following rules will allow it through:

iptables -A INPUT -p tcp --destination-port 1723 -j ACCEPT
iptables -A INPUT -p 47 -j ACCEPT

That is all I needed to do to get my clients connecting. It should be noted that the clients were all behind adsl routers (Dlink DSL 504, with forward PPTP turned on), More work needs to be done if your clients are behind a linux NAT box.

Several of my hosting customers have asked about creating htpasswd files in windows. I’ve found this howto which also links to the htpasswd.exe.