Broker domain on Unix server

[Seb_Barcelona]

Hi team,

I got a partner asking me a hard one here.
On a Windows server, you can specify the active directory asociated to a broker if it differs from the one the server is installed on, via a registry key modificationm following those steps:
1. Start-->Run , Enter "Regedit"
2. Choose HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services.
Highlight the Broker service you want to configure.
3. Click the "Parameters" key. Click the "Domain" string.
Enter the desired NETBIOS equivalent name of your domain/child domain in the
value field.
4. Close the Regedit. Restart your Broker Service.

This is all well and good, but what happens when the broker runs on a Unix machine? There's no registry to change there, so how can we specify the active directory to use for this server?

Thanks a lot in advance for your input.

BR,
Seb

[Seb_Barcelona]

Hi guys,

Thandava followed me that document from Steve Grantham that explains how to work this out.  As you can read this is no simple feat.
I've tried to upload the whole document here, but I don't seem to find the right option (if it's even possible) , so I've pasted the whole thing below, but if you want a copy of the original doc, ask me or Thandav.

/////////////////////////

One of the disadvantages of a mixed environment of Unix and Windows operating system platforms is the challenge of maintaining the multiple logins/passwords required by users and administrators. Unix vendors (notably Sun Microsystems) addressed the problem of unified logins years ago with the addition of the NIS subsystem, later enhanced as NIS+. Microsoft addressed the problem with the release of Windows NT with its domain structure, later enhanced in Windows 2000 as Active Directory.
 
Unfortunately, both solutions are platform-centric, i.e. the domain structure of Windows doesn’t allow simple interaction with Unix-based workstations and server, and vice versa for NIS. While Microsoft’s Services for Unix is a significant step forward toward the integration ideal, it may be overkill for some organizations to deploy and manage, and it currently doesn’t provide true single-signon capabilities.
 
Other vendors recognized the need for unified logins and produced solutions which tied the two platforms together, but many organizations can’t justify the cost of an additional management product, both in terms of purchasing it and in administering it.
 
One platform-agnostic solution to the quest for a single login is to use Kerberos 5 authentication to authenticate your Unix users using a Windows domain controller acting as a Kerberos Key Distribution Center. The Kerberos 5 connectivity software is included in both Windows Server and major Unix installations.
 
Ross Systems, Inc. develops, deploys, and supports our software on all major Operating System platforms, including Windows 2000/2003, HP-UX, AIX, Solaris, Tru64 and OpenVMS. Our Development and QA environments are complex, since all current versions of each Operating System are kept online and available for both software development and client support.
 
We conducted a simple test of using Kerberos 5 authentication by configuring a test environment with Windows 2003 Server and HP-UX 11.0 servers. For the HP-UX server, it was necessary to load a patch (J5849AA) which installed the complete Kerberos 5 toolset. For the Windows 2003 server, the tools were loaded from the Windows 2003 Server install CD (in \Support\Tools, double-click the SUPTOOLS.MSI file).
 
The Windows Server must be a domain controller in the domain which you want to use for authentication.
 
Time synchronization is critical between the two servers. Make sure that the Windows Time service (W32time) is configured and running, and that xntpd is configured and running on the Unix server.
 
The Ross test environment is diagrammed below:







Follow these steps to configure the authentication process:
 
[list=margin-top]
[*][Windows DC]  Create an account in Active Directory for the Unix server that the user will be logging into. This account should be a simple user account, standard security groups are adequate, and should have the Unix host name as the “First Name”, “User Logon  Name”, and “Display Name” in AD.  The server host name entry in AD will allow the Unix server to contact the KDC (Windows server) to request tickets for the users who will be logging in. You will still need user accounts in AD for each of the users who will log in via the KDC. For instance, in our testing we wanted a user named “testkerb” to login on the unix server named “garnet” via Kerberos. Our DC was named “beryl”, in the Rossdev.com domain. We therefore created two user accounts on the DC: the Unix server account (“garnet”) and the user account (“testkerb”).
[/list]
 
[list=margin-top]
[*]On the Windows DC, open a command prompt and execute ktpass.exe, with parameters as shown (substituting your own Unix host name/domain name).
[/list]
 
ktpass –princ <unix host>/<unix host>@<server>.your.domain.name –mapuser <unix host> -pass <account password> -out <unix host>.out.
 
In the example below, our Unix host name is garnet, our windows domain name is rossdev.com, our DC is beryl, and our password is 123asd098.
 
ktpass –princ garnet/garnet@beryl.rossdev.com -mapuser garnet -pass 123asd098 -out garnet.keytab
 
Windows will complain about the lowercase principal name but creates the appropriate keytab file anyway. Subsequent executions of ktpass for garnet will display an error regarding the SPN (ServicePrincipalName) creation, but these can be safely ignored: on the initial execution for a particular principal, ktpass will change the SPN mapping on the logon name from “garnet” to “garnet/garnet”, which only needs to happen once.
 
[list=margin-top]
[*]Identical syntax was used to create the testkerb keytab file. Once the server keytab file has been created successfully (and any additional user keytabs that you will need), move them to the appropriate Unix server via ftp or nfs. We found management of keytab files easier by storing them in a single folder. A more elegant solution would be to use Windows Services for Unix to create an NFS drive and mount it on the Unix server(s) being targeted. It would save some keystrokes to run the ktpass.exe from your NFS’ed drive/path, then access it on the unix boxes.
[/list]
 
 
 
[list=margin-top]
[*][Unix Server] After creating the keytab files and copying them to the Unix server(s), it’s time to configure Kerberos on Unix. This isn’t very complicated as long as you have a working DNS which can resolve hostnames and PAM (Pluggable Authentication Module) on the Unix server(s). PAM is included on all major Unix flavors and the configuration should be identical or very similar on each.
[/list]
 
[list=margin-top]
[*]Edit the /etc/krb5.conf file to point to your Windows DC (see example below).
[/list]
 
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 
[libdefaults]
 ticket_lifetime = 24000
 default_realm = ROSSDEV.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
default_tkt_enctypes = des-cbc-md5
default_tgs_enctypes = des-cbc-md5
 
[realms]
 ROSSDEV.COM = {
  kdc = BERYL.ROSSDEV.COM:88
  admin_server = BERYL.ROSSDEV.COM:749
  default_domain = ROSSDEV.COM
  kpasswd_server = BERYL.ROSSDEV.COM:464
 }
 
[domain_realm]
.rossdev.com = ROSSDEV.COM
rossdev.com  = ROSSDEV.COM
 
[kdc]
 profile = /var/kerberos/krb5kdc/kdc.conf
 
[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }
 
 
[list=margin-top]
[*]Once you’ve copied the keytab files to the unix server(s), use ktutil to merge them into the /etc/krb5.keytab file, which is the master keytab file. The syntax for ktutil is identical across Unix flavors:
[/list]
 
Ktutil  (brings up the CLI)
 
 
ktutil: rkt garnet.keytab      (reads in the specified .keytab file)
 
ktutil: wkt /etc/krb5.keytab        (merges it with krb5.keytab)
 
ktutil: q            (finished)
 
 
[list=margin-top]
[*]Once you’ve merged the appropriate keytab entries in the /etc/krb5.keytab file, you can test functionality of Kerberos using the kinit utility (on Unix servers). Login (or su) as the user whose keytab you want to verify, and issue the kinit command.
[/list]
 
kinit
 
If the configuration is correct, you should get a password prompt such as:
 
Password for testkerb@ROSSDEV.COM:
 
Type the correct password and kinit will retrieve a Kerberos Ticket Granting Ticket from the Windows server for the logged-in user. You can verify that this happened using klist:
 
# klist
Ticket cache: /tmp/krb5cc_14547_14564
Default principal: testkerb@ROSSDEV.COM
 
Valid starting     Expires            Service principal
09/13/04 09:44:26  09/13/04 19:43:32  krbtgt/ROSSDEV.COM@ROSSDEV.COM
#
 
[list=margin-top]
[*]After you have successfully requested and received a Kerberos ticket granting ticket, you should use the kdestroy command to destroy it. You should be able to change your password on the Unix server using the kpasswd command (note that root can’t change another users password, this must be done on the Windows server).
[/list]
 
[list=margin-top]
[*]After verifying that communications between the servers are working (with kinit, kpasswd, klist, etc), you can configure PAM on the Unix server(s) which will bring all appropriate services under the Kerberos authentication umbrella, using the /etc/pam.conf file (on HP-UX 11.0). Once PAM has been configured correctly to use the Windows KDC, the creation and export of *.keytab files should not be necessary as long as all password management takes place on the Windows KDC. Again, however, it is necessary for the user to have a valid account on the Unix box in order to log in.
[/list]
 
A sample pam.conf file is show below from the Ross HP-UX system. For a more detailed look at the options available in pam.conf, see your man pages or server documentation.
 
#
# PAM Configuration
#
# Account Management
#
login     account  required  /usr/lib/security/libpam_krb5.1
login     account  required  /usr/lib/security/libpam_unix.1
su        account  required  /usr/lib/security/libpam_krb5.1
su        account  required  /usr/lib/security/libpam_unix.1
dtlogin   account  required  /usr/lib/security/libpam_krb5.1
dtlogin   account  required  /usr/lib/security/libpam_unix.1
dtaction  account  required  /usr/lib/security/libpam_krb5.1
dtaction  account  required  /usr/lib/security/libpam_unix.1
ftp       account  required  /usr/lib/security/libpam_krb5.1
ftp       account  required  /usr/lib/security/libpam_unix.1
OTHER     account  required  /usr/lib/security/libpam_unix.1
#
# Authentication Management
#
login     auth  sufficient /usr/lib/security/libpam_krb5.1
login     auth  required   /usr/lib/security/libpam_unix.1  try_first_pass
su        auth  sufficient /usr/lib/security/libpam_krb5.1
su        auth  required   /usr/lib/security/libpam_unix.1  try_first_pass
dtlogin   auth  sufficient /usr/lib/security/libpam_krb5.1
dtlogin   auth  required   /usr/lib/security/libpam_unix.1  try_first_pass
dtaction  auth  sufficient /usr/lib/security/libpam_krb5.1
dtaction  auth  required   /usr/lib/security/libpam_unix.1  try_first_pass
ftp       auth  sufficient /usr/lib/security/libpam_krb5.1
ftp       auth  required   /usr/lib/security/libpam_unix.1  try_first_pass
OTHER     auth  required   /usr/lib/security/libpam_unix.1
#
#
# Password Management
#
login      password       required   /usr/lib/security/libpam_krb5.1
login      password       required   /usr/lib/security/libpam_unix.1 
passwd     password       required   /usr/lib/security/libpam_krb5.1
passwd     password       required   /usr/lib/security/libpam_unix.1 
dtlogin    password       required   /usr/lib/security/libpam_krb5.1
dtlogin    password       required   /usr/lib/security/libpam_unix.1 
dtaction   password       required   /usr/lib/security/libpam_krb5.1
dtaction   password       required   /usr/lib/security/libpam_unix.1 
OTHER      password       required   /usr/lib/security/libpam_unix.1
#
# Session Management
#
login    session   required  /usr/lib/security/libpam_krb5.1
login    session   required  /usr/lib/security/libpam_unix.1
dtlogin  session   required  /usr/lib/security/libpam_krb5.1
dtlogin  session   required  /usr/lib/security/libpam_unix.1
dtaction session   required  /usr/lib/security/libpam_krb5.1
dtaction session   required  /usr/lib/security/libpam_unix.1
OTHER    session   required  /usr/lib/security/libpam_unix.1
 
 
The pam.conf above depends entirely for authentication on the KDC. It is possible to allow both systems (KDC and Unix) to authenticate users—see your documentation.
 
 
 


Summary:
 
Our test was successful, but there are a few caveats. We didn’t configure for dual authentication (KDC/Unix), which would be a more robust configuration (if the KDC is unavailable, for instance, your Unix boxes will still be accessible). This is done in the pam.conf file, see your man pages. Using the pam_users exception file, it is possible to exempt the root user from KDC authentication, which might be a desirable effect.
 
We were not able to make the Unix kpasswd command function correctly, no doubt a bit more tweaking would allow this. Kpasswd should allow users on the Unix boxes to change their passwords at the Unix level, and have the changes propagated to the Windows KDC.
 
Kerberos 5 authentication provides single-login functionality for Unix/Windows systems. Combined with Windows Services for Unix and the creation of a few scripts, the process of sharing system resources can be almost completely automated. Keep in mind that Kerberos 5 is created to provide login/password authentication only, it has nothing to do with system permissions, which are still maintained on the Unix server(s). Implementation across a variety of Unix systems is possible since Kerberos 5 is available on modern *nix distributions.  It is still necessary for users have accounts on the Unix boxes, so a certain amount of redundancy is unavoidable. The Kerberos configuration detailed here is for single-sign-on password authentication only.
 
The links below provide more detailed information about various Kerberos (and other) security configurations. Before implementing a Kerberos-based single-sign-on solution, take the time to study the available documentation, and design a solution that matches you own organization’s needs. Note that these links are accurate as of the publication of this document, and may have changed by the time you are reading this.
 
 
Configuration Guide for Kerberos Products on HP-UX :
 
http://docs.hp.com/hpux/onlinedocs/J5849-90003/J5849-90003.html
 
PAM-based Distributed Authentication (from the Samba Team):
 
http://info.ccone.at/INFO/Samba/pam.html#id2959266
 
A basic cookbook for a simple PAM-based Kerberos configuration (this was helpful but not complete):
 
http://barney.gonzaga.edu/~awithers/integration/