During my travels on the internet, I came across a really interesting blog post by Roberto Bouza of Miami, Florida, United States in which he explains and documents his experiences with synchronising AIX 5.3 with Windows Active Directory.

I felt it would be useful to share this information with you and for ease I have copied the content of Roberto’s blog directly into mine, although I do not want to steal his fire in any way, so if you have any comments to offer regarding his article then please visit his site directly at: http://www.robertobouza.com/2009/12/tech-cubby-aix-active-directory.html If what I am doing is wrong or violates some form of “Best Practices for reposting others blog posts” then please contact me and let me know what I should be doing.

So here goes with the technical stuff.

This document is for AIX 5.3 Systems with the oslevel at 5300-10 or 11. So issuing the command $> oslevel -s should give you the information you need.

After checking this we’ll need a few packages to get things going. Since IBM’s packages are, how can I say this… incomplete, we’ll require the help of our pware friends. So you can go to the downloads section at pware.hvcc.edu and download the following packages (even if you already have them on your system. They will be installed on a different location- you’ll find there as well some helpful information about how to set up samba and pware software in general):


Then we’ll run on the folder were we downloaded the files $> inutoc . that will generate a .toc file that we will use to install all this packages. Now let’s run on the same directory $> smitty an on the menu that will show click on: “Software Installation and Maintenace” -> “Install and Update Software” -> “Install Software” on the “INPUT device / directory for software” write ./ that just means use the local directory. Hit enter, go to “ACCEPT new license agreements?”, click on tab to change to yes and hit enter (twice). This will install all the packages on /opt/pware .

Now that we have the basic packages in place, we just need some configuration files. Let’s start with kerberos. Copy the /opt/pware/share/examples/krb5/krb5.conf to /etc and change the parameters to fit your environment. Down below is the one I’m using in my environment (with some stripped fields).

— krb5.conf – start —


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


default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes


kdc = AD_Server_1.example.com
kdc = AD_Server_2.example.com
kdc = AD_Server_3.example.com


— krb5.conf – ends —

Usually the default_realm is the part that is left when the host name is stripped out of the FQN of the server, let’s say AD_Server_1.example.com then the domain will be example.com. It needs to be on capitals, don’t forget in CAPITALS.

Once the krb5.conf file has been configured. We can get a ticket from the domain controller. A ticket is like the key to the domain, is the way we can communicate with the server in a secure way. To do this, we need to do a few changes first.

Add to the /etc/environment the following (or replace some of the environment variables):

— A piece of the /etc/environment – start —



— /etc/environment – end —

Then execute $> exec bash to get a bash shell. If this doesn’t work, just go to /opt/pware/bin and execute just $> bash

Once you are on bash, let’s get the environment variables available doing $> source /etc/environment

Ok, we are set to get that kerberos ticket. I hope that you already got your AD account with domain registration privileges, if not go and ask the Microsoft admins for one. Maybe you’ll get it in a week or two, don’t worry the blog post still be here. :-)

Execute $> kinit [AD username] this will ask you for a password, just fill that in and if everything goes well, you are not going to see anything, just the bash cursor again “$>” if you see something, then is time to use Google for some research because I’m sure you got an error… please do not use Bing. :-)

Make sure that the firewall ports are open, that you can ping the AD server and telnet to the AD ports, just do a basic check of all the basic things.

Now that we have our ticket let’s go an configure samba. Samba is actually the heart of this, the tip of the mountain. Their winbind plug-in has come a long way, and I think as of right now is a ver powerful tool. So let’s copy the example file from /opt/pware/lib/smb.conf.default to /opt/pware/lib/smb.conf and tweak the variables on the [global] section. Please read below my global configuration.

— smb.conf [global] section – start —

server string = “IBM AIX server”
workgroup = example
password server = *
security = ads
idmap uid = 100000-200000
idmap gid = 100000-200000
idmap backend = rid:”bftg-nt=100000-200000″
template homedir = /home/users/%U
template shell = /opt/pware/bin/bash
interfaces = en0
winbind enum users = Yes
winbind enum groups = Yes
winbind nested groups = Yes
winbind separator = +
winbind use default domain = true
winbind offline logon = true

— smb.conf [globa] section – end —

Let’s pay attention to a few important things here. First, the workgroup variable is the name of the Windows AD domain. When you see you AD username is something like user/workgroup, is the main name of your AD domain (nothing to do with your FQN domain). Secondly the realm is the same default_realm as the one we used on the krb5.conf file (it needs to be CAPITALS). Then finally we have the idmap directive, which is the one that will help us map SIDs to UIDs and GIDs. Samba has an algorithm which translates per domain the ids and make them unique. Then way you can assign permission of the AIX box even if the user is not configured there. Isn’t that neat?

Then we have some other winbind directives one that is important is the separator and the default domain. The separator is the one which splits the username/group from the workgroup name returned from AD. The default domain is the one that says that you can use only your name to authenticate without using the long user/workgroup syntax. You can use the directives that you see on my example. It works.

Ok, I’m already tired, just writing all this stuff. So now that we have samba configured, let’s go ahead and register the AIX server into the network. Just run $> net ads join -U[AD username] don’t leave spaces between the -U and the [AD username], all goes together. Then you’ll be prompted for your password and if everything goes ok, you should see something like

$> net ads join -U[AD username]

Enter [AD username]’s password:

Using short domain name — EXAMPLE

Joined ‘AIXSERVER’ to realm ‘example.com’


So if you are curious, then you’ll want to go to the Users, Groups and Computers administration tool on windows, do a search in your domain and the server AIXSERVER should be there. Now, something to be very careful, is that adding the server to the domain also adds all the interfaces the server has to the DNS server (if you are using the Microsoft DNS server in conjunction with your AD server). So if your server has 10 interfaces is going to add 10 entries to the DNS server, and if they are private IPs, then no one will be able to connect to the box. So, first grab that main IP you are using to connect, and as soon as the DNS entries are updated, go ahead and delete all the entries and add the real ones.

Let’s start the winbind daemon and do some queries. Let’s go ahead and issue the command $> winbindd let’s do a $> ps -edalf | grep winbindd to make sure it is up and running and finally let’s do a query to the Ad server like this $> wbinfo -u or $> wbinfo -g you should see all the users in you domain or the groups. If you don’t see them… once again start doing some Google research and not Bing research please.

So at this point, we are almost ready. We are 90% done. Our server is authenticating with AD, so to make it available when logging into the box we need to change the default user stanza and the login methods. Let’s go ahead and edit the /etc/security/user file and change the SYSTEM variable with this:

SYSTEM = “WINBIND or compat”

Go ahead and edit the /usr/lib/security/methods.cfg and add at the end:


program = /usr/lib/security/WINBIND

So what are we doing here? well, we are telling AIX that from now on it should use winbind as the authentication method for users (default users). Users that are already defined on the system and are not on AD will be able to log in. We also left the compat method on the default stanza so if winbind fails it will check locally.

If you have telnet enabled you can go ahead and try to log in from another box into the AIX server with your AD username and password. You should be able to log in. Remember to configure the home directory of your users as seen on the smb.conf file (/home/users/%U – were %U is the AD username). You’ll be able to log in but your home will be / if your real home directory is not created (better yet how about using automount to get your users homes in all the servers that you configure from now on – I’ll leave that to you :-)

If you don’t want to use telnet and prefer using SSH. Remember to change the UseLogin directive on the sshd_config file to yes UseLogin Yes that will delegate the authentication to winbind.

I hope this will help someone get it done fast and easy.