Translate

Monday 28 July 2014

An interesting LDAP feature

Many people use LDAP to store vital information such as usernames and passwords, and sudo rules, and this information should always protected as much as possible. The ideal soltion is to configure Secure LDAP and have all your traffic encrypted using a certificate. The problem is that you have to start somewhere and it is always easier to start with the most basic configuration, and add functionality as you go.

The easiest and supported method for configuring an AX server as an AIX client is to use the mksecldap command. This method not only configures the "/etc/ldap/ldap.cfg" configuration file, it tests the actual connection and adds an entry to the "/etc/inittab" which ensures that LDAP starts during boot.

ldapclntd:23456789:wait:/usr/sbin/start-secldapclntd  > /dev/console 2>&1



Assuming everything is working you should be able to test your connection:

# ls-secldapclntd
ldapservers=ldap-server.mydomain.local
current ldapserver=ldap-server.mydomain.local
ldapport=389
active connections=1
ldapversion=3
usercachesize=1000
usercacheused=3
groupcachesize=100
groupcacheused=3
usercachetimeout=300
groupcachetimeout=300
heartbeat interval=300
numberofthread=10
connectionsperserver=10
authtype=UNIX_AUTH
searchmode=ALL
defaultentrylocation=LDAP
ldaptimeout=60
serverschematype=SFUR2
userbasedn=OU=AIX,DC=mydomain,DC=local
groupbasedn=OU=AIX,DC=mydomain,DC=local
userobjectclass=user,person,organizationalperson
groupobjectclass=group


and retrieve some data e.g.

# lsldap
dn: OU=AIX,DC=mydomain,DC=local

dn: CN=Builtin,DC=mydomain,DC=local

dn: CN=Computers,DC=mydomain,DC=local

d...

..

As you used a username (binddn) and password (bindpwd) to make the connection these credentials are stored in the "ldap.cfg" e.g.

binddn:CN=myhost,OU=AIX,DC=domain,DC=local
bindpwd:{DESv2}65 C1ADCD69A$F 973F44541DAC97E66A78DEF1B5FA97EFF

According to IBM this password has been salted and the file cannot be copied to another system, however this is not the case as you can actually create a single file and copy it to all your hosts, and just add the entry to "/etc/inittab" and this gives you a really quick way to build a test environment, however what happens if you want to change the password, or make every host bind using a different name?

The convential wisdom is to create an account that matches the hostname of each server. This works nicely but if you want to do this you also need to run mksecldap on each host, or do you?

If you are sticking to one user for all and just want to change the password you can simply run mksecldap on one host, disctribute the "ldap.cfg" and restart the daemons, however you create a new password by running:

# /usr/sbin/secldapclntd -e <new-password>

and then append this to the "bindpwd:" entry and recycle the daemon. The interesting part is that this new password is SALTED and so cannot be copied to another system, which means if you want to script this, it has to run on each target machine.

Note: If you are testing/are unsure about a password you can simply enter the plain-text, restart the daemon, and this will also work, but should obviously be repaced ASAP.

The other thing to consider is that if your LDAP server(s) is not available during boot, your AIX server will hang. It is therefore worth considering replacing "wait" with "once".




Thursday 3 July 2014

Using Putty to login

We are being told everyday not to use simple passwords or to use the same password on multiple sites, which is good advice, however what is the best alternative?

If you use Putty to connect to your AIX or Linux systems you can create an OpenSSH key-pair using the PuttyGen application and then copy the key to your AIX host, which then enables you to login with requiring a password, however the disadvantages to this approach are:

  • There is no way to prevent a user from having a key without any pass-phrase, or to control the quality, content, or age, etc. Therefore if somebody has access to their PC they can login without a password, and/or steal the key.
  • If you are at home, or in another remote location where you don't have access to your private-key file, and you have turned-off password authentication, you are stuck. This also applies if you lose the key file.

One possible solution is to restrict root or your normal account(s) to SSH key-only authentication, and then set-up a restricted rescue-account that has as little functionality and privilege as possible except that it enables you to su/sudo.

Many hackers routinely scan port 22 for SSH services and then try to guess the root password so one possibility is to setup a dedicated service on port 443 as most firewalls allow HTTPS/SSL traffic, and hackers would not normally notice SSH on this port.