Samba for AIX 5.3 & 6.

1
(by William Jojo) (20090624)

1. 2. 3. 4.

5.

6.

Introduction Installing the binaries Tuning AIX Configuring a basic domain controller (a) Password database options i. smbpasswd ii. tdbsam iii. ldapsam (b) Group Mappings (c) Machine Accounts (d) User/Group Manipulation Integration with Active Directory (a) Setting up Kerberos (b) What time is it? (c) IDMAP Overview (d) WINBIND (e) IDMAP_TDB (f) IDMAP_LDAP (g) Testing IDMAP (h) What does this error mean? Backups and Upgrades (a) OpenLDAP (b) Samba

AIX, POWER and pSeries are a registered trademarks of the IBM Corporation. EMC is a registered trademark of the EMC Corporation Samba is op!right Andre" #ridge$$ and the Samba #eam and is $i ensed %nder the &P'() $i ensing mode$ *&P'(+ %p to ).,.+-b.

Samba for AIX 5.3 & 6.1 (20090624)

1 of 37

1. Introduction
This document assumes a few things: 1. You are the administrator of AIX or have some direct access to the operating systems as a privileged user and you've kept it fairly well up to date. Most problems can be avoided with keeping AIX at recent levels. Use the link provided to get the updates you need before you get started. It is recommended that you stick to TL's (Technology Levels) or SP's (Service Packs to a TL) and only install specific APARs when you need a specific fix. http://www14.software.ibm.com/webapp/set2/sas/f/genunix3/aixfixes.html 2. You are using the AIX binary packaging at the pWare site. 3. You've planned your disk space, have a rough count of the number of users and machines that will be participating and have some basic system administration experience in AIX. That said, you should already be thinking about the infrastructure you want to either build or enhance. There will be some points along the way where you will pause, reflect and begin to change your perspective about how you're going to roll out Samba. It is advised that you go with that feeling (at least on paper). 4. You've consulted your users, other system administrators and department heads as needed to be certain your plans achieve the goals of all involved. There is no cookie cutter solution, nor is this a black art. Simply put, if you fail to plan, you plan to fail. Several options will be presented based on the capabilities of the author, the software and the operating system (but mostly the capabilities of the author). All of which may show deficiencies at some level. This is natural and expected with both humans and software. When this happens in software there will often be a work around offered to assist you. This content was tested with AIX 5.2 up to TL10-00 and AIX 5.3 up to TL09-02 and AIX 6.1 up to TL03-01 The following files will be modified or created so you should consider making a backup of each of them before getting started:
/usr/lib/security/methods.cfg /etc/security/user /etc/security/ldap/ldap.cfg /etc/slapd.conf /opt/pware/lib/smb.conf

Special thanks to all those who have been testing the AIX binaries against Active Directory, especially Samba for AIX 5.3 & 6.1 (20090624) 2 of 37

Selwyn Marock. Some very interesting error messages have been collected in the What does this error mean? section with specific fixes noted when these errors occur. Conventions:
mono mono bold mono bold italic

file names, commands and options to configuration. command line text typed by the user. notable details.

Samba for AIX 5.3 & 6.1 (20090624)

3 of 37

2. Installing the Binaries

By this time you've downloaded or are about to download the binaries from the Samba site. If you've downloaded these before and performing and upgrade, you may not need the opt-samba-base again. Check the README file for details. You will need the following from the pWare site http://pware.hvcc.edu :
pware53-AIX53-Samba-3.3.4.tar.gz

This package can be found in the download section under aix53 or aix53-64. In addition, you will need the following IBM filesets available from the AIX installation media: For AIX 5.3, they are:
ldap.client.rte ldap.client.adt

For AIX 6.1 they are:

idsldap.clt32bit61.rte idsldap.clt_max_crypto32bit61.rte idsldap.cltbase61.adt idsldap.cltbase61.rte

On AIX 6.1 you will also need to run the following script from IBM (which comes with idsldap.cltbase61.rte) to make sure the symlinks are correct for the secldapclntd daemon to resolve LDAP lookups:
/opt/IBM/ldap/V6.1/bin/idslink

If you are upgrading a version of the base software or Samba, you are advised to backup all of your configuration and TDB files prior to upgrading. Simply place all of the files in a directory in /tmp, uncompress and extract the tarballs and take a moment to ponder what you are about to do. Then follow the installation instructions in the README file. That file is the source of up to the minute installation instructions, known issues and work-arounds and will not be repeated here. Once installed, you should see the following with lslpp:
[tstsmb:/] # lslpp -l pware* Fileset Level State Description ---------------------------------------------------------------------------Path: /usr/lib/objrepos pware !"base"rte "!"#"# $%&&'(()D p*are base +or "! pware !"b,b"rte -"."/0"- $%&&'(()D 1er2ele3 D1 -"."/0 pware !"c3rus-sasl"rte /"0"//"/ $%&&'(()D c3rus-sasl /"0"//

Samba for AIX 5.3 & 6.1 (20090624)

4 of 37

pware pware pware pware pware pware pware pware pware pware pware

!"4ette5t"rte !"2rb "rte !"libiconv"rte !"ncurses"rte !"openl,ap"rte !"openssh"rte !"openssl"rte !"popt"rte !"rs3nc"rte !"samba"rte !"?lib"rte

#"06"#"# 0"."!"0 0"0/"#"# "6"#"0 /"-"0."# "/"0"# #"=">"0# 0"0#"-"# !"#" "# !"!" "# 0"/"!"#

$%&&'(()D $%&&'(()D $%&&'(()D $%&&'(()D $%&&'(()D $%&&'(()D $%&&'(()D $%&&'(()D $%&&'(()D $%&&'(()D $%&&'(()D

789 4ette5t #"06 &'( :erberos 0"."! 789 libiconv 0"0/ ncurses "6"#"0 %penLD;P /"-"0. %penSS< "/p0 %penSSL #"=">j popt 0"0#"rs3nc !"#" Samba !"!" ?lib 0"/"!

This software can also be installed through the SMIT utility using:
smitty install

If you received errors during the installation process be sure that you have all of the filesets in the same directory so that dependencies can be resolved. Be certain too that you've agreed to the licensing terms. The licensing terms, simply put, are that these packages are provided without warranty and, they are governed by several licensing models. If something breaks, neither I nor my employer are responsible. I have made every effort to make this as painless and expeditious as possible and hope you enjoy using these fine products.

Samba for AIX 5.3 & 6.1 (20090624)

5 of 37

3. Tuning AIX
There are two basic means by which to tune AIX the command line and at the next boot. Some tunable values are dynamic and other require a reboot to take effect. The three basic categories of tunable values (there are others, but these matter the most) are: 1. Virtual Memory (vmo) 2. I/O (ioo) 3. Network (no) The parenthetic value is the command that directly controls these tunable values. The format of these commands is very simple and is explained in detail in the their respective manual pages. What follows is a set of values used at our site for optimal throughput of SAN-connected disk, Gigabit network connectivity and a fairly good amount of system memory. With roaming profiles and about 1000 student workstations, the server is currently a pSeries p650-6M2 6-way 1.2GHz POWER4+ LPAR (although 4-way is enough), 14GB of memory and dual-attached redundant pathway 2Gb Fiber Channel back to an EMC CX-700 SAN. You should build your system to the specifications necessary for your environment. The values are as follows and are taken from the /etc/tunables/nextboot file:
ioo: numclust = "1024" numfsbufs = "6144" j2_nPagesPerWriteBehindCluster = "8192" minpgahead = "0" j2_minPageReadAhead = "0" vmo: maxperm% = "80" maxclient% = "70" minfree = "4096" maxfree = "4608" strict_maxperm = "0" strict_maxclient = "1" lru_file_repage = "0" arptab_nb = "311" arptab_bsiz = "23" ipqmaxlen = "2000" nbc_limit = "0" tcp_ttl = "128" udp_ttl = "128" extendednetstats = "1"

no:

Samba for AIX 5.3 & 6.1 (20090624)

6 of 37

rfc1323 = "1" tcp_sendspace = "262144" tcp_recvspace = "262144" udp_sendspace = "65536" udp_recvspace = "655360" sb_max = "1048576" use_isno = "0" clean_partial_conns = "1"

Just some quick comments. The values for ioo reflect the fact that under heavy load, the use of sequential read-ahead can actually be a penalty during a high degree of multiprogramming when processes are waiting around for large chunks of data to fulfill the the upper bound on read-ahead, whilst hundreds of other processes do the same. Liberal use of write-behind is used due to the fact that we have good caching on the SAN. The values for vmo reflect the level of multiprogramming and the amount of I/O. We do not want AIX swapping processes out to disk for the sake of better I/O, so maxperm% and maxclient% were lowered. The minfree and maxfree values are tuned higher due to the amount of data being moved which makes more pages available for I/O so that lrud (the least recently used daemon in charge of finding/stealing pages) is more efficient in many but certainly not all cases. The values for no represent the use of excellent networking equipment, beefy server hardware and an excellent attachment to our disk subsystem. Your mileage may vary! One other place to make some changes if you haven't since the installation of AIX from CD-ROM is the /etc/security/limits file which usually contains these defaults:
default:

fsize = 2097151 core = 2097151 cpu = -1 data = 262144 rss = 65536 stack = 65536 nofiles = 2000

These numbers need to be increased at least for the root user. The default stanza below shows a good starting point to be certain that all of your services will have sufficient memory and file handles.
default:

fsize = 2097151 core = 2097151 cpu = -1 data = 524288 rss = 524288 stack = 524288 nofiles = -1

Samba for AIX 5.3 & 6.1 (20090624)

7 of 37

The bulk of this is left to the reader to assess their own tuning needs as the values presented may be too high for your particular site, so read the manual pages and collect some metric data to determine a baseline first before making any changes. It is your responsibility to make bootable backups of your system in case these values render your system non-bootable. If you wish to share some experiences with tunable values on your hardware, feel free to drop me a line and I'll see about getting them into future version of this document.

Samba for AIX 5.3 & 6.1 (20090624)

8 of 37

4. Configuring a Basic Domain Controller

The domain controller (DC) is a basic unit of measure when setting up Samba. Security is set to user level security and the DC is configured to accept authentication from machines that have trusts established with Samba. What follows is a series of basic configurations depending on your needs as far as where the user authentication database is kept and whether you need to run winbindd. The nmbd and smbd daemons are minimally required to run Samba. Here is a basic smb.conf file to get started with. All subsequent examples play off of this example showing the specific differences. Some of the highlighted portions are related to some upcoming discussions and the administrator should research others for a clear understanding of their meanings.
[global] workgroup = DOMNAME map to guest = Bad User passdb backend = smbpasswd max log size = 100000 time server = Yes socket options = TCP_NODELAY SO_SNDBUF=262144 SO_RCVBUF=262144 logon script = current.bat logon drive = h: domain logons = Yes encrypt passwords = yes os level = 60 preferred master = Yes domain master = Yes short preserve case = No csc policy = disable oplocks = No level2 oplocks = No strict locking = No log level = 0 # sync unix side password in /etc/security/passwd unix password sync = yes passwd program = /opt/pware/sbin/passwd.ksh %u passwd chat = "*password*\n*password:" %n\n "*password:" %n\n "*" #passwd chat debug = yes hosts allow = 127., 192.168. [homes] comment = Home Directories path = %H read only = No create mask = 0644 force create mode = 0644 force directory mode = 0755 use sendfile = Yes browseable = No [netlogon] comment = Network Logon Service path = /netlogon

Samba for AIX 5.3 & 6.1 (20090624)

9 of 37

browseable = No

The [homes] and [netlogon] stanzas are standard fare and this is a typical configuration to get you started. See the many How To's and manual pages at the Samba site for specific details of these options. Note: The smbpasswd command is used in all three sections for password database options. This is due to the fact that the smbpasswd command is backend neutral and the configuration file for Samba dictates where and how user attributes should be handled. 4a. Password Database Options i. smbpasswd The default and simplest choice for a small amount of users that requires the least amount of knowledge and can be administered by a single individual is the use of smbpasswd(5). This file is a flat text file that is similar in format to /etc/passwd, that is, there are colon separated fields that represent specific data values that are Samba sensitive. Users must first be created in AIX using the mkuser command. And then added to the smbpasswd file using the smbpasswd(8) command. The smbpasswd file is located in the private directory of the Samba install path (for this example is it in /opt/pware/private/smbpasswd). All users and machine accounts will have entries in both files. Some may say that this method is antiquated and irrelevant. Fine, believe what you will, but the setup of LDAP for less than 300 users may not be worth the effort and disaster recovery planning necessary, especially if this Samba server is the only one and not going to be trusting or be trusted by other servers. Some items to note in the configuration is the passdb backend which is explicitly set to the default of smbpasswd. (NOTE: in Samba 3.4.0 the default backend will be tdbsam.) Synchronizing the AIX password with the Samba password is desirable when users may be logging into AIX with telnet, ftp, ssh or scp. Users may then gain alternate access to their data. This next script (save it as passwd.ksh) is used for the passwd program option. That option with password chat allows Samba to change the AIX user password as well when requesting the Samba password be changed. This is not always necessary, but if you want to login to AIX with the same username and password as Samba, then you'll need this.
#!/bin/ksh # script to change user password because of unix passwd s # second command removes the ADMCHG flag from /etc/security/passwd # put there by passwd running as root. /usr/bin/passwd $1 /usr/bin/pwdadm -c $1

Note: If you are intending to synchronize passwords with AIX, you need the script above to be saved Samba for AIX 5.3 & 6.1 (20090624) 10 of 37

with the execute bit on, and Samba must be started for this to work. Setting the password as root accesses the smbpasswd file directly, but for the passwd program to be invoked, you have to become the user which then makes the call through a connected smbd. Check the /etc/security/passwd file to be certain your user's AIX password was set. If it wasn't, check your smb.conf for correctness and check permissions on scripts to make sure they have been made executable. This sounds blatantly obvious, but is so easy to overlook. You can start Samba with the following commands:
/opt/pware/sbin/nmbd -D /opt/pware/sbin/smbd -D

Verify that the daemons are running before proceeding. Check the logs in the /opt/pware/var directory for hints on what might be wrong. The winbindd daemon is only necessary if you need security identifier (SID) translation of foreign SID's to local AIX UID or GID mappings. This is necessary when you are a domain member server or using trusts between Samba servers, between Samba and NT or between Samba and AD. Another reason to use winbindd is if you intend to use an option like ldapsam:editposix (q.v.). If you are not using any the aforementioned configurations or are running a single domain controller, you do not need winbindd. Using the mkuser command and the following script (save it as smbpass.ksh), we can quickly assemble a list of users and even automate the process into another script that could run daily based on user data acquired from another source. (In other words, if you're an educational institution and the administrative computing system can give you the needed information about students who've registered since yesterday, you can automate the process of account creation.)
#!/bin/ksh [[ $# -ne 2 ]] && echo "Usage: smbpass.ksh user pass\n" && exit 1 # add user and set xxx for password. /opt/pware/bin/smbpasswd -s -a $1 <<EOF xxx xxx EOF # become user, set the real password so that the AIX passwd is set too. su $1 "-c /opt/pware/bin/smbpasswd -s" <<EOF xxx $2 $2 EOF

So using the above script saved into a file called setpass.ksh (with the execute bit on), you would do the following as the root user:

Samba for AIX 5.3 & 6.1 (20090624)

11 of 37

# mkuser newid gecos=New User Name # setpass.ksh newid newpassword

If you need more AIX user attributes, simply string along more options for the mkuser command. There are two simple tests you can now perform to make sure this user is working. The first is the AIX login test try to login to AIX with something simple like telnet or ftp. The next test is to try to view your share using smbclient(8):
[root] # smbclient //127.0.0.1/newid --user=newid Password: Domain=[DOMNAME] OS=[Unix] Server=[Samba 3.0.25b] smb: \> dir . D 0 Thu Jul 12 07:53:25 2007 .. D 0 Thu Jul 12 08:00:59 2007 .profile AH 254 Thu Jul 12 07:53:25 2007 32768 blocks of size 4096. 31570 blocks available smb: \> quit

That's it! smbpasswd user authentication is now configured for Samba with password synchronization in AIX. ii. tdbsam Using the smbpasswd section as a guide, we will change one line in our [global] section to the following:
passdb backend = tdbsam

After starting Samba this creates a passdb.tdb directory in the /opt/pware/private directory of the Samba install path. You can use the exact same tools described in the smbpasswd section above for adding your users to AIX and Samba. Password synchronization with AIX will be maintainable as well. The Samba documentation has indicated that some sites have had as many at 3000+ users in this particular backend with no noticeable latency issues. Since the tdb files are binary in nature and not flat files like the smbpasswd file, you may want to consider looking into tdbbackup(8) for disaster recovery. iii. ldapsam When faced with possibly 10000+ usernames that need to be created for authentication, it's hard to beat LDAP for its ability to store and retrieve data rapidly. Add some database indexes and some decent caching and you will have a splendid authentication subsystem. Samba for AIX 5.3 & 6.1 (20090624) 12 of 37

One should plan ahead and setup a filesystem dedicated to the storage of LDAP data. This can get pretty big and you want to have plenty of headroom so that there is space for the log files (used for recovery if needed). A few gigabytes is good to start. AIX allows you to grow filesystems, so you can start small and monitor your usage and increase as needed. This discussion is limited to RFC-2307 style attributes and only discusses the use of OpenLDAP as it is packaged with the other Samba AIX binaries. We will, however, discuss the integration of LDAP users into AIX so that it reflects the same level of ability as previously stated in the smbpasswd and tdbsam sections. Keep in mind that the intention is to have Samba store additional attributes of users that have been defined in LDAP using AIX commands. This is a commitment of user accounts in LDAP that are known to AIX and could be used to log into AIX. These user accounts will be further enhanced by Samba attributes. First, we will start without Samba running and a new [global] stanza for smb.conf:
[global] workgroup = DOMNAME map to guest = Bad User max log size = 100000 time server = Yes socket options = TCP_NODELAY SO_SNDBUF=262144 SO_RCVBUF=262144 logon script = current.bat logon drive = h: domain logons = Yes encrypt passwords = yes os level = 60 preferred master = Yes domain master = Yes short preserve case = No csc policy = disable oplocks = No level2 oplocks = No strict locking = No log level = 0 passdb backend = ldapsam:"ldap://127.0.0.1" ldap admindn = cn=Manager,dc=domname,dc=local ldap group suffix = ou=groups ldap user suffix = ou=people ldap machine suffix = ou=people ldap idmap suffix = ou=idmap ldap suffix = dc=domname,dc=local ldap passwd sync = yes [homes] comment = Home Directories path = %H read only = No create mask = 0644 force create mode = 0644 force directory mode = 0755 use sendfile = Yes browseable = No

Samba for AIX 5.3 & 6.1 (20090624)

13 of 37

[netlogon] comment = Network Logon Service path = /netlogon browseable = No

Now we will step away from Samba for a bit and configure LDAP. This will use the filesystem /ldap for the examples and will have a directory under that for this database and will use /ldap/db/domname.local for the database path. In that directory we will place a file called DB_CONFIG with the following contents:
set_cachesize 0 134217728 1 set_lg_regionmax 262144 set_lg_bsize 2097152

This DB_CONFIG is a good place to start and provides 128MB of solid caching that rarely needs increasing unless you've a great deal of data. Now let us create a slapd configuration file, /etc/slapd.conf, which will layout the LDAP database in detail including schema file, attributes to be indexed and access rights. It will look much like this:
include include include include include include include pidfile argsfile /opt/pware/etc/openldap/schema/core.schema /opt/pware/etc/openldap/schema/cosine.schema /opt/pware/etc/openldap/schema/inetorgperson.schema /opt/pware/etc/openldap/schema/nis.schema /opt/pware/etc/openldap/schema/misc.schema /opt/pware/etc/openldap/schema/samba.schema /opt/pware/etc/openldap/schema/aixadmin.schema /opt/pware/var/slapd.pid /opt/pware/var/slapd.args

loglevel 0 reverse-lookup on allow bind_v2 password-hash {crypt} conn_max_pending 1024 conn_max_pending_auth 1024 threads 16 database bdb suffix "dc=domname,dc=local" sizelimit 50000 directory /ldap/db/domname.local cachesize 500000 checkpoint 1024 15 rootdn "cn=Manager,dc=domname,dc=local" rootpw secret index objectClass eq index cn pres,eq,sub index sn pres,eq,sub

Samba for AIX 5.3 & 6.1 (20090624)

14 of 37

index index index index index index index index index

mail pres,eq,sub uid pres,eq,sub memberUid eq uidNumber eq gidNumber eq sambaSID eq,sub sambaDomainName eq sambaPrimaryGroupSID default sub,eq

eq

access to dn.subtree="ou=people,dc=domname,dc=local" attrs=userPassword by peername.ip=127.0.0.1 read by peername.ip=151.103.16.50 read by self write by * auth access to dn.subtree="ou=people,dc=domname,dc=local" attrs=sambaLMPassword,sambaNTPassword by peername.ip=127.0.0.1 write by * none access to dn.subtree="ou=people,dc=domname,dc=local" by peername.ip=127.0.0.1 write by * none access to dn.subtree="ou=groups,dc=domname,dc=local" by peername.ip=127.0.0.1 write by * none access to dn.subtree="ou=idmap,dc=domname,dc=local" by peername.ip=127.0.0.1 write by * none access to dn.subtree="dc=domname,dc=local" by peername.ip=127.0.0.1 write by * none

There is a great deal being said in this configuration file and you should consult the OpenLDAP documentation for details. This is basically broken down as the following:

which schema files to include some basic local configuration the database definition including indexes to be created the access control list (ACL's).

This will help define a tree in LDAP whose root or suffix is dc=domname,dc=local. Beneath the root we will have several containers, in the form of organizational units (ou) which are called ou=people for the usernames, ou=groups for the Unix groups and ou=idmap for winbindd information (this container along with winbindd is only used if Samba will be trusting another Samba server or will be a Domain Member Server of an AD tree). Ordinarily we would put our machine accounts in ou=computers, but since we will be using AIX to create the accounts, it cannot discern the difference. This will result in distinguished names (dn) that will look like the following: Samba for AIX 5.3 & 6.1 (20090624) 15 of 37

uid=newid,ou=people,dc=domname,dc=local

This dn is the LDAP entry for the AIX username newid and is also shown in Illustation 1. Since we want to include Samba attributes, we will also need to copy a file from the Samba installation into the schema as follows:
cp /opt/pware/examples/LDAP/samba.schema \ /opt/pware/etc/openldap/schema

Illustration 1: LDAP Tree hierarchy. And since AIX is providing the means to get our users into LDAP, create a file /opt/pware/etc/openldap/schema/aixadmin.schema with the following lines:
attributetype (1.3.18.0.2.4.756 name 'AIXAdminGroupId' DESC 'AIX new admin group id storage' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetype (1.3.18.0.2.4.776 name 'AIXAdminUserId' DESC 'AIX new admin user id storage' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetype (1.3.18.0.2.4.782 name 'AIXGroupID' DESC 'AIX new group id storage' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetype (1.3.18.0.2.4.770 name 'AIXUserID' DESC 'AIX new user id storage' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) objectclass ( 1.3.18.0.2.6.169 NAME 'AIXAdmin'

Samba for AIX 5.3 & 6.1 (20090624)

16 of 37

DESC 'AIX class to store user/group administration attributes' SUP top STRUCTURAL MUST cn MAY ( AIXAdminGroupId $ AIXAdminUserId $ AIXGroupID $ AIXUserID ) )

Now that the files are in place, we need a baseline LDIF (lightweight directory interchange format) file to create the tree in LDAP. This will create our empty containers. So create a file domname.ldif with the following:
dn: dc=domname,dc=local dc: domname objectClass: top objectClass: dcObject objectClass: organization o: My Organization Name # remove this container if using sectoldif dn: ou=people,dc=domname,dc=local ou: users objectClass: organizationalUnit #remove this container if using sectoldif dn: ou=groups,dc=domname,dc=local ou: groups objectClass: organizationalUnit dn: ou=idmap,dc=domname,dc=local ou: idmap objectClass: organizationalUnit

We will now load this data into the LDAP database with the following command:
/opt/pware/sbin/slapadd -f /etc/slapd.conf -l domname.ldif

If all has gone well, and it should have, you should now see more files including the DB_CONFIG file within the /ldap/db/domname.local directory. NOTE: This next bit of instruction only works for AIX 5.3 TL-03 or later. If we are migrating users from /etc/passwd to LDAP, you can perform the following two commands to create the LDIF file and load it into LDAP:
sectoldif -d dc=domname,dc=local -S RFC2307 >/tmp/migrate.ldif /opt/pware/sbin/slapadd -f /etc/slapd.conf -l /tmp/migrate.ldif

Samba for AIX 5.3 & 6.1 (20090624)

17 of 37

If you are not migrating anything from AIX into LDAP, you will still need the ou=system container for the AIX uid/gid information to be used for the creation of subsequent users and groups via mkuser and mkgroup. The container can be obtained from the last three stanzas of sectoldif output even if you're not migrating the existing users. The container is based on the information contained in /etc/security/.ids and looks like this:
dn: ou=System,dc=domname,dc=local ou: System objectClass: organizationalUnit dn: cn=aixid,ou=System,dc=domname,dc=local cn: aixid objectClass: aixadmin aixadminuserid: 8 aixuserid: 203 aixadmingroupid: 14 aixgroupid: 202 dn: cn=aixbaseid,ou=System,dc=domname,dc=local cn: aixbaseid objectClass: aixadmin aixadmingroupid: 1 aixadminuserid: 1 aixuserid: 200 aixgroupid: 200

You can put this LDIF data into a file /tmp/aixid.ldif and import it using the slapadd command similar to the one above substituting /tmp/aixid.ldif for /tmp/migrate.ldif. The database is loaded so let's get slapd started with the following command:
/opt/pware/libexec/slapd -f /etc/slapd.conf

Querying the database will reveal that we have successfully loaded the database and that the slapd daemon is running.
/opt/pware/bin/ldapsearch -LLL -x -D cn=Manager,dc=domname,dc=local \ -w secret -b dc=domname,dc=local

Now we have to get AIX ready to do some work for us. This stanza indicates where AIX can find information about users that could log into the AIX system (not what Samba can do). Samba needs to ask AIX what the uid/gid values are for users and the groups for which they are members. The /etc/security/user file will be altered to arrange for such knowledge. If we do not want anyone defined in /etc/passwd (with the exception of the root user) to be able to login to AIX and only allow LDAP users, then we could set the default stanza's SYSTEM value to LDAP. AIX users in /etc/passwd cannot login unless they were migrated using sectoldif or have a userspecific stanza that has SYSTEM=compat in the body (or whatever is appropriate for your site). However, Samba for AIX 5.3 & 6.1 (20090624) 18 of 37

we can allow both as is demonstrated in the following example. The file /etc/security/user needs the default stanza attribute of SYSTEM set to "LDAP or compat", like so (the ellipses are showing lines removed to reduce clutter):
default: admin = false login = true su = true ... umask = 022 expires = 0 SYSTEM = "LDAP or compat" logintimes = ...

NOTE: Never change the root stanza to point to LDAP! If you have filesystem or data corruption in the LDAP database or if LDAP fails to start, you will not be able to login. The next section simply tells AIX about another means to find users and groups. The LDAP program being placed in this file is known as a loadable authentication module (LAM) and will assist AIX in finding our LDAP users. Now edit /usr/lib/security/methods.cfg and add the following:
LDAP: program = /usr/lib/security/LDAP program_64 = /usr/lib/security/LDAP64

And finally we'll configure the secldapclntd daemon to report our users using our LDAP database. The file /etc/security/ldap/ldap.cfg should be backed up and the contents replaced with:
ldapservers:127.0.0.1 binddn:cn=Manager,dc=domname,dc=local bindpwd:secret authtype:ldap_auth useSSL: no userattrmappath:/etc/security/ldap/2307user.map groupattrmappath:/etc/security/ldap/2307group.map idattrmappath:/etc/security/ldap/aixid.map userbasedn:ou=people,dc=domname,dc=local groupbasedn:ou=groups,dc=domname,dc=local idbasedn:cn=aixid,ou=system,dc=domname,dc=local userclasses:posixaccount,shadowaccount,account groupclasses:posixgroup ldapport:389 followaliase:NEVER usercachesize: 1000 groupcachesize: 100 cachetimeout: 300 heartbeatinterval: 300

Samba for AIX 5.3 & 6.1 (20090624)

19 of 37

numberofthread: 10 connectionsperserver: 10 searchmode:ALL defaultentrylocation:local ldaptimeout:60

Now AIX needs a little help in understanding our tree and its attributes. The map files in /etc/security/ldap help AIX to understand. The 2307user.map file needs a line added for the password attribute which indicates if the account is allowed to login.
username id pgrp home shell gecos spassword lastupdate password SEC_CHAR SEC_INT SEC_CHAR SEC_CHAR SEC_CHAR SEC_CHAR SEC_CHAR SEC_INT SEC_CHAR uid uidnumber gidnumber homedirectory loginshell gecos userpassword shadowlastchange description s s s s s s s s s

The description attribute is selected because we already have user information in the gecos attribute and description in an acceptable attribute in the account structural objectclass listed in the userclasses line of the ldap.cfg file. The secldapclntd daemon provides AIX with user information by way of the LDAP LAM mentioned described above. Now we can start the secldapclntd program to provide this user information using the following command:
start-secldapclntd

Once started you should be able to list all of your LDAP users with:
lsuser -R LDAP ALL

And we can create a user with:

mkuser -R LDAP gecos="My New UserID" newid

And check it with:

lsuser -R LDAP newid

Now back to Samba. We'll need to start Samba at this point and then we can add our user newid to Samba for AIX 5.3 & 6.1 (20090624) 20 of 37

Samba.
/opt/pware/sbin/nmbd -D /opt/pware/sbin/smbd -D # /opt/pware/bin/smbpasswd -a newid New SMB password: Retype new SMB password: Added user newid.

An ldapsearch of the newid user reveals the following:

dn: uid=newid,ou=people,dc=domname,dc=local gidNumber: 1 uidNumber: 203 homeDirectory: /home/newid loginShell: /usr/bin/ksh gecos: My New UserID description: * uid: newid cn: newid objectClass: posixAccount objectClass: shadowAccount objectClass: account objectClass: sambaSamAccount sambaSID: S-1-5-21-959677704-806820969-3419776215-1406 displayName: My New UserID sambaLMPassword: 78BCCAEE08C90E29AAD3B435B51404EE sambaNTPassword: F9E37E83B83C47A93C2F09F66408631B sambaPasswordHistory: 00000000000000000000000000000000000000000000000000000000 00000000 sambaPwdLastSet: 1186884501 sambaAcctFlags: [U ] userPassword:: e2NyeXB0fU9ELm1jNlRFNDdrS2M= shadowLastChange: 0

The attributes added by Samba have been highlighted. AIX created the other attributes for this dn. One thing to note is there had not previously been a userPassword nor shadowLastChange attribute. These were created as a result of the fact that we have ldap passwd sync enabled in smb.conf. This is splendid since we can set the Samba password for the user and the Unix password will be updated automatically. Even if this is not necessary for AIX access, many products use the userPassword attribute by way of the ldap_bind() function which is a part of the OpenLDAP API. Sidebar: This will lead the reader to the logical conclusion that it is possible to have single-sign-on across multiple products such as Samba, AIX, Apache, Mirapoint, FreeRADIUS and others. Do not confuse single-sign-on with pass-through authentication. That is not what has been described here. Samba for AIX 5.3 & 6.1 (20090624) 21 of 37

Rather a means for a single user to gain access to multiple authenticated resources by way of a single set of credentials. This method can only be achieved by all other authenticated resources using this same LDAP server. I leave the details of such a setup to the reader and perhaps I will draft a separate document if time allows. At this point these users cannot log into AIX since their password field (the description attribute) is still an asterisk (*) and needs to be an exclamation point (!) for logins to be allowed. To change this simply use:
pwdadm -c newid

Now we can test our account to see how we've done.

[root] # smbclient //127.0.0.1/newid --user=newid Password: Domain=[DOMNAME] OS=[Unix] Server=[Samba 3.0.25b] smb: \> dir . D 0 Sat Aug 11 12:35:58 2007 .. D 0 Sat Aug 11 12:35:58 2007 .profile AH 254 Sat Aug 11 12:35:58 2007 smb: \> quit [root] # 32768 blocks of size 4096. 32672 blocks available

Excellent! You are now ready to begin your journey of how to further integrate the Samba server into your environment. This is not an easily prescribed solution as much of this has been. You must take great care in your decision making since a bad choice now may result in great pain and possibly a wet cleanup in aisle 4. In conclusion, when you reboot your system the services we've started above will not be automatically restarted. You can add some lines to /etc/inittab to auto start these services, or you can write a script to do so after the system is up and running and the root user has been granted access. Be certain all of your filesystems have been mounted and you should be able to get underway with the following set of commands:
/opt/pware/libexec/slapd -f /etc/slapd.conf start-secldapclntd /opt/pware/sbin/nmbd -D /opt/pware/sbin/smbd -D

Samba for AIX 5.3 & 6.1 (20090624)

22 of 37

4b. Group Mappings

Mapping AIX groups to Samba group relative identifier (RID) values is essential for at least the basic set of well known group security identifiers (SID). These group/RID pairs are shown in the following table: Domain Admins Domain Users Domain Guests Domain Computers 512 513 514 515

If this is a new AIX installtion, you can simply match the gid to the SID's RID for ease of use, otherwise you'll have to create the AIX groups with different gid values and map those to the well known RID values i Here is a SID:
S-1-5-21-959677704-806820969-3419776215-1406

This SID is actually the one created for newid from our previous section. The S-1-5-21 prefix will be common to nearly all of the SID's in this domain. The next three values, 959677704-8068209693419776215, are relative to this domain controller (DC) and the last value, 1406, represents the RID for the object in question. If we don't map our groups, the SID values will default to S-1-22-2-gid. To have our AIX groups possess Samba SID values, make the AIX groups with the following commands:
mkgroup mkgroup mkgroup mkgroup -R -R -R -R LDAP LDAP LDAP LDAP id=512 id=513 id=514 id=515 domadmin domuser domguest domcomp

Then create the group mappings with:

net groupmap add rid=512 unixgroup=domadmin type=domain \ ntgroup="Domain Admins" net groupmap add rid=513 unixgroup=domuser type=domain \ ntgroup="Domain Users" net groupmap add rid=514 unixgroup=domguest type=domain \ ntgroup="Domain Guests" net groupmap add rid=515 unixgroup=domcomp type=domain \ ntgroup="Domain Computers"

Verify your mappings with:

Samba for AIX 5.3 & 6.1 (20090624)

23 of 37

[root] Domain Domain Domain Domain

# net groupmap list Admins (S-1-5-21-959677704-806820969-3419776215-512) -> domadmin Users (S-1-5-21-959677704-806820969-3419776215-513) -> domuser Guests (S-1-5-21-959677704-806820969-3419776215-514) -> domguest Computers (S-1-5-21-959677704-806820969-3419776215-515) -> domcomp

An ldapsearch of the domadmin group reveals the following:

dn: cn=domadmin,ou=groups,dc=domname,dc=local gidNumber: 512 cn: domadmin objectClass: posixGroup objectClass: sambaGroupMapping sambaSID: S-1-5-21-959677704-806820969-3419776215-512 sambaGroupType: 2 displayName: Domain Admins description: Domain Unix group

The attributes added by Samba have been highlighted. AIX created the Unix group with the nonhighlighted attributes. Why do we want these group mappings? Well, the Windows view of the share will show these groups and any others you wish to map when looking at the security tab for an object on that Samba share. For example, perhaps you would like to map the AIX staff (gid:1) group to Site Staff Users. Simply use net groupmap add to do so, then on the Windows side when viewing the security information, instead of seeing the object's group mapped to staff (Domain Unix Group) you would see it mapped to Site Staff Users.

4c. Machine Accounts

This is actually an easy topic to discuss. Machine accounts are just like regular user accounts with the exceptions that they are all in upper case, end with a dollar sign ($) and represent actual equipment on the network. So a typical machine account will look like COMP001$ as a basic user account. Create machine accounts just like you would a regular user account. Remember that since AIX does not differentiate between users and machines, they will all be in the same ou=people container. Create a machine account using the following commands:
[root] # mkuser -R LDAP gecos=Computer 1 pgrp=domcomp COMP001$ [root] # smbpasswd -a -m COMP001$ Added user COMP001$.

Note that smbpasswd was not fully qualified with the installation path. The use of the -m option on smbpasswd indicates that this is a machine account and therefore doesn't prompt you for a password since the real password will be established when the computer with that name joins this domain. Samba for AIX 5.3 & 6.1 (20090624) 24 of 37

An ldapsearch of COMP001$ machine account reveals the following:

dn: uid=COMP001$,ou=people,dc=domname,dc=local uidNumber: 204 homeDirectory: /home/COMP001$ loginShell: /usr/bin/ksh gecos: Computer 1 gidNumber: 515 description: * uid: COMP001$ cn: COMP001$ objectClass: posixAccount objectClass: shadowAccount objectClass: account objectClass: sambaSamAccount sambaSID: S-1-5-21-959677704-806820969-3419776215-1408 displayName: Computer 1 sambaLMPassword: 37BC2047D596FB57AAD3B435B51404EE sambaNTPassword: 755D4E81FE5D7FA9C10B559481C255E5 sambaPwdLastSet: 1186932416 sambaAcctFlags: [W ]

The attributes added by Samba have been highlighted. The default Samba passwords are the encryptions of the machine account that has been converted to lower case and the dollar sign removed (comp001).

4d. User/Group Manipulation.

There comes a time when a user needs to belong to more than one group, should be removed from a group or the user access needs to be disabled. To add a user newid to the domuser group using the AIX chgrpmem command:
chgrpmem -R LDAP -m + newid domuser

Inversely, you can remove remove newid from the domadmin group using:
chgrpmem -R LDAP -m - newid domadmin

Note the use of plus (+) and minux (-) to add and remove membership (-m). You can also check membership as follows:
[root] # lsuser -R LDAP -a groups newid

Samba for AIX 5.3 & 6.1 (20090624)

25 of 37

newid groups=staff,domuser [root] #

Disable and enable a Samba account with the following:

[root] # /opt/pware/bin/smbpasswd -d newid Disabled user newid. [root] # [root] # /opt/pware/bin/smbpasswd -e newid Enabled user newid. [root] #

Samba for AIX 5.3 & 6.1 (20090624)

26 of 37

5. Integration With Active Directory

Integrating Samba with Active Directory (AD) is a real snap. If you've done your AD homework, have configured the AD controller correctly and setup DNS, then you are well on your way. All that is needed now is to configure Kerberos so we can get an initial ticket granting ticket, configure Samba to utilize Kerberos and then attempt to join the tree. Setting up Kerberos The first step is to configure Kerberos and to run kinit to verify we can talk to AD. The file /etc/krb5.conf will look something like this:
[logging] default = FILE:/var/log/krb5/libs.log kdc = FILE:/var/log/krb5/kdc.log admin_server = FILE:/var/log/krb5/admin.log [libdefaults] default_realm=DOMNAME.LOCAL [realms] DOMNAME.LOCAL = { kdc = 192.168.100.100 }

You should create the directory /var/log/krb5 for the logging section of the configuration. What time is it? Kerberos is time sensitive. Clock skew can be the cause of many Samba-AD integration issues. It is recommended that all of your servers run ntpd or a similar daemon that will keep the clocks up to date. AIX provides the xntpd daemon whose configuration file is /etc/ntp.conf. Unfortunately it is not configured for you. You may use the following configuration which includes some standard pool servers in the United States:
broadcastclient driftfile /etc/ntp.drift tracefile /etc/ntp.trace server 0.us.pool.ntp.org server 1.us.pool.ntp.org server 2.us.pool.ntp.org server 3.us.pool.ntp.org

Details about the pool servers for your region can be found at http://www.pool.ntp.org/.

Samba for AIX 5.3 & 6.1 (20090624)

27 of 37

You can start the ntp service with the following command:
[root] # startsrc -s xntpd 0513-059 The xntpd Subsystem has been started. Subsystem PID is 471286. [root] #

This service can be automatically started at boot time by uncommenting the line in /etc/rc.tcpip that starts this service. Now we can perform the kinit as follows:
[root] # kinit administrator Password for administrator@DOMNAME.LOCAL: [root] #

IDMAP Overview The IDMAP subsystem is a method by which users and groups from a remote domain (whether AD, NT or another Samba domain) can be mapped to local accounts on a Unix server and thereby gain access to resources or have their access restricted to only certain resources. In other words, Unix need to know how to identify these foreign users and groups since neither AIX nor Samba is actually administering them. This also means that foreign SID's are mapped to local uid/gid values. These values must not collide with uid/gid values in use on this system and therefor must have their own separate range specified. This also provides a means by which this data is long lived. We must have a mapping from a SID<->uid or SID<->gid that lasts (presumably) forever. Otherwise if the underlying uid/gid changes, it no longer represents the user it once did. Ok, so we don't really know anything about the foreign users, but why is this really necessary? One word permissions. Unix stores permissions (rwx), ownership and group information per object in a filesystem. Without IDMAP, how would you make an object owned by a user in a foreign domain? How would you allow the members of groups from three different domains access to one of your shares? Face it you need IDMAP. Which also means you need winbindd. The winbindd daemon is the universal translator for all things foreign. As we will see, winbindd will provide a great deal for us as will the WINBIND loadable authentication module for AIX. WINBIND The WINBIND loadable authentication module was created as a means to directly link Windows users into AIX and subsequently enable all the commands that have the -R option to display and work with these user accounts. One only need add another stanza to /usr/lib/security/methods.cfg like was previously done with the LDAP module. A symbolic link for WINBIND is already setup

Samba for AIX 5.3 & 6.1 (20090624)

28 of 37

Add the following lines to /usr/lib/security/methods.cfg:

WINBIND:

program = /usr/lib/security/WINBIND

AIX is now prepared to deal with users in other domains and use them as if they were local accounts. The next few sections deal with connecting Samba to those domains and contain commands that work with WINBIND. IDMAP_TDB The smb.conf presented here is for Samba to be a simple domain member server which is the extent of the AD role for Samba 3. We will start with idmap_tdb, move to idmap_ldap and conclude with idmap_ad. The smb.conf for idmap_tdb looks similar to the following:
[global] workgroup = DOMNAME security = ADS encrypt passwords = yes realm = DOMNAME.LOCAL client use spnego = yes winbind separator = + idmap idmap idmap idmap idmap idmap domains = DOMNAME config DOMNAME:default = yes config DOMNAME:backend = tdb config DOMNAME:range = 200000 - 500000 alloc backend = tdb alloc config:range = 200000 - 500000

We have instructed Samba to store our idmap data in a tdb (trivial database) file. This means we cannot share this information with another Samba server. You can now jump ahead to Testing IDMAP.

Samba for AIX 5.3 & 6.1 (20090624)

29 of 37

IDMAP_LDAP Following in the tradition of the previous section, we will now introduce the smb.conf for using LDAP as the IDMAP backend. You will notice that the information is similar, but tailored to additional configuration complexity of LDAP. Also, Samba is down at the moment.
[global]

workgroup = DOMNAME security = ADS encrypt passwords = yes realm = DOMNAME.LOCAL client use spnego = yes winbind separator = + log level = 2 interfaces = 192.168.100.60/24 wins server = 192.168.100.100 ldap admin dn = cn=Manager,dc=domname,dc=local idmap domains = DOMNAME idmap config DOMNAME:default = yes idmap config DOMNAME:backend = ldap idmap config DOMNAME:ldap_base_dn = ou=idmap,dc=domname,dc=local idmap config DOMNAME:ldap_user_dn = cn=Manager,dc=domname,dc=local idmap config DOMNAME:ldap_url = ldap://127.0.0.1/ idmap config DOMNAME:range = 200000 - 500000 idmap alloc backend = ldap idmap alloc config:ldap_base_dn = ou=idmap,dc=domname,dc=local idmap alloc config:ldap_user_dn = cn=Manager,dc=domname,dc=local idmap alloc config:ldap_url = ldap://127.0.0.1/ idmap alloc config:range = 200000-500000

[netlogon] path = /netlogon

For information on setting up the ou=idmap container, refer to the ldapsam part of section 4a. The configuration once again shows we are a domain member server in ADS. It also defines a domain, DOMNAME, along with the range used for mapping foreign SIDs and the alloc configuration specifying what dn has the rights to map a SID to a uid/gid and what container in LDAP will hold this information. Store the set of secrets for DOMNAME and alloc using the following commands:
[root] Secret [root] Secret # net idmap secret DOMNAME secret stored # net idmap secret alloc secret stored

The secrets are necessary since we do not have the complete authentication credentials for the ldap_user_dn specified in the configuration. It is also possible that we could have additional domains specified in the configuration for which we are not responsible for allocating, but could access with a different set of credentials. This is why we set the ldap_user_dn and store a secret for each section. Samba for AIX 5.3 & 6.1 (20090624) 30 of 37

Testing IDMAP With Samba shutdown and the kinit already done, we will now join the Active Directory tree:
[root] # net ads join -U administrator@DOMNAME.LOCAL administrator@HVCC.LOCAL's password: Using short domain name -- HVCC Joined 'DEV53' to realm 'HVCC.LOCAL' [root] #

Once joined, start Samba:

/opt/pware/sbin/nmbd -D /opt/pware/sbin/smbd -D /opt/pware/sbin/winbindd -D

Now the users from the other domain should be visible to us. The wbinfo command will help us to determine what we can see. In the following output SUBDOM is a subdomain of DOMNAME.LOCAL so it appears in the output. The commands for listing users and groups are as follows:
[root] # wbinfo -u SUBDOM+administrator SUBDOM+guest SUBDOM+krbtgt SUBDOM+domname$ SUBDOM+jojowil DOMNAME+administrator DOMNAME+guest DOMNAME+support_388945a0 DOMNAME+krbtgt DOMNAME+subdom$ [root] # wbinfo -g SUBDOM+domain computers SUBDOM+domain controllers SUBDOM+domain admins SUBDOM+domain users SUBDOM+domain guests SUBDOM+group policy creator owners SUBDOM+dnsupdateproxy BUILTIN+administrators BUILTIN+users DOMNAME+helpservicesgroup DOMNAME+telnetclients DOMNAME+dhcp users DOMNAME+dhcp administrators DOMNAME+domain computers DOMNAME+domain controllers DOMNAME+schema admins DOMNAME+enterprise admins

Samba for AIX 5.3 & 6.1 (20090624)

31 of 37

DOMNAME+cert publishers DOMNAME+domain admins DOMNAME+domain users DOMNAME+domain guests DOMNAME+group policy creator owners DOMNAME+ras and ias servers DOMNAME+dnsadmins DOMNAME+dnsupdateproxy

You may receive the error, Error looking up domain users or Error looking up domain groups. This can happen when first starting Samba and trying the wbinfo command. It may take as long as 15 minuted to display users, otherwise, start looking at the logs and verify your configurations to be certain they are correct. You should also verify that you set the correct idmap secrets when using IDMAP_LDAP. If you've added WINBIND, you can use the lsuser command to view more information about a user in the SUBDOM domain.
[root] # lsuser -R WINBIND subdom+jojowil subdom+jojowil id=200000 pgrp=SUBDOM+domain users home=/home/SUBDOM/jojowil shell=/bin/false gecos=William Jojo login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=WINBIND SYSTEM=LDAP logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0 minother=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks= dictionlist= fsize=-1 cpu=-1 data=524288 stack=524288 core=2097151 rss=524288 nofiles=-1 roles= id=200000 pgrp=SUBDOM+domain users home=/home/SUBDOM/jojowil shell=/bin/false gecos=William Jojo shell=/bin/false pgrp=SUBDOM+domain users SID=S-1-5-212077368256-2853265561-1504360347-1104

A few notable items in the output have been highlighted. The id value is the first value in the range we previously specified in the idmap config and idmap alloc options of smb.conf. The foreign user's SID is also listed. If you are using IDMAP_TDB, then in the /opt/pware/var/locks directory, you should notice a file called winbindd_idmap.tdb. This file contains the foreign SID to uid/gid mappings that will remain permanent throughout this trust between the Samba server and the Active Directory server. The contents of the file can be viewed with the following command:
[root] # tdbdump /opt/pware/var/locks/winbindd_idmap.tdb { key(11) = "GID 200002\00" data(8) = "S-1-0-0\00" } { key(47) = "S-1-5-21-2077368256-2853265561-1504360347-1104\00" data(11) = "UID 200000\00" }

Samba for AIX 5.3 & 6.1 (20090624)

32 of 37

{ key(46) = "S-1-5-21-2077368256-2853265561-1504360347-513\00" data(11) = "GID 200003\00" } { key(11) = "UID 200000\00" data(47) = "S-1-5-21-2077368256-2853265561-1504360347-1104\00" } { key(9) = "USER HWM\00" data(4) = "A\0D\03\00" } { key(11) = "GID 200003\00" data(46) = "S-1-5-21-2077368256-2853265561-1504360347-513\00" } { key(8) = "S-1-0-0\00" data(11) = "GID 200002\00" } { key(10) = "GROUP HWM\00" data(4) = "D\0D\03\00" } { key(14) = "IDMAP_VERSION\00" data(4) = "\02\00\00\00" }

Otherwise, if you are using IDMAP_LDAP, we can discover the same information using the following command: {FIX ME} At this point, we can see the users and groups and use them to assign permissions and ownership as demonstrated here:
[root] # mkdir /tmp/billdir [root] # chown domname+administrator /tmp/billdir [root] # aclget /tmp/billdir * * ACL_type AIXC * attributes: base permissions owner(DOMNAME+administrator): rwx group(system): r-x others: r-x extended permissions disabled [root] # chown subdom+jojowil /tmp/billdir [root] # chgrp "domname+domain users" /tmp/billdir

Samba for AIX 5.3 & 6.1 (20090624)

33 of 37

[root] # aclget /tmp/billdir * * ACL_type AIXC * attributes: base permissions owner(SUBDOM+jojowil): rwx group(DOMNAME+domain users): others: r-x extended permissions disabled

r-x

Now the only thing left to discuss is the fact that WINBIND users cannot log into AIX directly. But, of course, we can fix that. Simply change the SYSTEM value for default user stanza in /etc/security/user:
default:

admin = false login = true su = true ... umask = 022 expires = 0 SYSTEM = "WINBIND" logintimes = ...

Keep in mind that any users previously defined in /etc/passwd will have trouble when committing to this configuration. Without a stanza for those particular users, they will be locked out. A way to resolve this would be to list all the possible values appropriate for the SYSTEM value such as:
SYSTEM = "WINBIND or LDAP or compat"

Samba for AIX 5.3 & 6.1 (20090624)

34 of 37

What does this error mean? Q:

[dev53:/opt/pware/lib] # kinit adminitrator@HVCC.LOCAL kinit(v5): Client not found in Kerberos database while getting initial credentials

A: The username is misspelled. ------------------------------------------Q:

[svc2:/opt/pware/bin] # kinit administrator Password for administrator@HVNET.HVCC.local: kinit(v5): Preauthentication failed while getting initial credentials

<or> Q:
[svc2:/opt/pware/bin] # kinit administrator Password for administrator@HVNET.HVCC.local: kinit(v5): KDC reply did not match expectations while getting initial credentials

A: The REALM information in /etc/krb5.conf is not in all uppercase. ------------------------------------------Q:

[2007/06/27 18:20:51, 0] utils/net_ads.c:ads_startup_int(286) ads_connect: No logon servers Failed to join domain: No logon servers

A: No WINS for the DC. Either find a WINS server or add to lmhosts. Also check that DNS resolves the DC correctly. ------------------------------------------Q:
[svc2:/opt/pware/bin] # net ads join -U administrator administrator's password: Failed to join domain: Operations error

A: No available DNS data for the DC. Either point to a favorable DNS server or add the DC to /etc/hosts (which should have been done already). Unless your REALM does not follow the DNS tree Samba for AIX 5.3 & 6.1 (20090624) 35 of 37

for your site. In which case see "Failed to set servicePrincipalNames" in the next Q:. ------------------------------------------Q:
[svc2:/opt/pware/bin] # net ads join -U administrator administrator's password: Using short domain name -- SUBDOM Failed to set servicePrincipalNames. Please ensure that the DNS domain of this server matches the AD domain, Or rejoin with using Domain Admin credentials. Deleted account for 'SVC2' in realm 'SUBDOM.DOM.LOCAL' Failed to join domain: Type or value exists

<or> Q:
[svc2:/opt/pware/bin] # net ads join -U administrator administrator's password: Failed to join domain: Invalid parameter

A: First the former error was generated joining W2k3 in mixed mode and the latter was generated joining W2k3 in 2003 mode. There may also be a slight variation in the former error where it claims "Disabled account" and not "Deleted account" When using a .LOCAL domain configuration that doesn't match your current DNS tree, an entry in /etc/resolv.conf is not enough to finish the communication. You need to add an entry for the Samba server (using its real IP and real FQDN as known to the DNS) to /etc/hosts (or fix DNS so it knows about your Samba server's fully-qualified and unqualified name):
10.1.1.10 svc2.realdom.com svc2

One site in the U.K. (thank you Selwyn for discovering this!) needed to split this data across two lines for reasons unknown to us. So it read like:
10.1.1.10 svc2.realdom.com 10.1.1.10 svc2

Samba for AIX 5.3 & 6.1 (20090624)

36 of 37

6.

Backups and Upgrades

{FIX ME}

Samba for AIX 5.3 & 6.1 (20090624)

37 of 37