1. A Simple ‘Single Sign on’ Method for HP-UX and Active Directory Domains, using Kerberos Client and Winbind
Don McCall
HP WTEC

2. Introduction Single signon the ‘holy grail’ some methods exist already
Kerberos+ldap+MS-SFU
Complicated and requires MS ADS changes
Pam_winbind
A good solution, but not currently available on HP-UX
Also currently uses challenge/response, not kerberos for authentication.
There has been a LOT written with regard to integrating authentication/authorization between HP-UX and Active Directory users. Samba, LDAP, Kerberos, Microsoft Active Directory, and Microsoft Services For Unix (SFU) all get pulled in, configured, tweaked and tuned, all in the name of a very simple requirement; allowing users defined and maintained in the Microsoft Active Directory to access HP-UX systems.[1] This concept is commonly referred to as ‘single sign on’, and the desired result is to allow a user to have a single set of authentication/authorization credentials (username/password) that he can use either to access his Microsoft Active Directory OR HP-UX resources. From an administration standpoint, there is a further requirement that these credentials be defined and maintained in a central place (the Active Directory), so that management of the credentials remains simple. In this paper, I’d like to present a method for doing just that, using Kerberos for authentication and Winbind for authorization against a Microsoft Windows Active Directory.[2]
[1] “Integrating HP-UX 11.x Account Management and Authentication with Microsoft Windows 2000”
[2] A method similar to this exists on Linux with the ‘pam_winbindd’ module, which works with the winbind daemon to authenticate users against a windows domain controller; however this module is only available on Linux platforms, not HP-UX.
18 September September 2018

3. Problem Statement
HP-UX system currently using /etc/passwd for local unix user authentication
Need to grant login/ftp access to users in existing MS ADS domain
Do not want to ‘shadow’ MS users with HP-UX users
Need to keep it simple – no ldap or ADS experience in the HP-UX administration staff.
I live in a very Active Directory/Microsoft-centric world. Most of the 20 odd members of my worldwide team do most of their work on Windows servers and clients. We have a DNS domain set up specifically for all of our Microsoft h/w that’s scattered across the globe, and we use Active Directory so that all of us can access any of these systems with a single set of credentials. I needed to add our HP-UX h/w into this domain, and take advantage of the credentials management already in place for my team. Many of these team members need to be able to log in via telnet, or ftp, and access files, directories, printers, and actually run HP-UX applications. I do NOT want to create new HP-UX users to mirror the usernames they already use to access AD resources. I also do not want to have to install or configure additional components (like SFU) on my Windows Active Directory servers, or have to configure the LDAP-UX client software on my HP-UX box.
18 September September 2018

4. Initial conditions HP-UX system name: walnut.wtec.diagnostic.hp.com
HP-UX authentication method: simple /etc/passwd authentication
swlist shows that the following products are installed:
B8725AA HP CIFS Server...
PAM Kerberos PAM-Kerberos …
Active Directory KDC: mccalldc.wtec.diagnostic.hp.com
Kerberos realm: WTEC.DIAGNOSTIC.HP.COM
Active Directory user name: moby
Active Directory user password: fishlips
Active Directory user ‘moby’ is a member in: ‘Domain Users’,’engineering’
moby has no access to the HP-UX system ‘walnut’, as he is NOT defined in the /etc/passwd file.
HP-UX system name: walnut.wtec.diagnostic.hp.com
HP-UX authentication method: simple /etc/passwd authentication
swlist shows that the following products are installed:
B8725AA HP CIFS Server...
PAM Kerberos PAM-Kerberos …
Note: Winbind is provided in the HP CIFS Server product bundle. Libpam_krb5.1 is provided in the PAM Kerberos product bundle. Neither of these products is a part of the core, but both are available as free downloads at software.hp.com:
Active Directory KDC: mccalldc.wtec.diagnostic.hp.com
Kerberos realm: WTEC.DIAGNOSTIC.HP.COM
Active Directory user name: moby
Active Directory user password: fishlips
Active Directory user ‘moby’ is a member in: ‘Domain Users’,’engineering’
moby has no access to the HP-UX system ‘walnut’, as he is NOT defined in the /etc/passwd file.
18 September September 2018

5. Target conditions
MS user moby should be able to telnet to HP-UX system ‘walnut’
Needs access to application ‘LabStats’
Only moby gets access to ‘LabStats’
We want ‘moby’ to be able to telnet into the HP-UX server ‘walnut’ and be able to run the application ‘LabStats’, which is being created especially for him. ONLY ‘moby’ should have access to this application. We do NOT want to have to create an HP-UX ‘moby’ user – we want all management of this user to occur within the Windows Active Directory instead.
18 September September 2018

6. Our solution Kerberos for authentication against MS KDC
Winbind authorization using MS ADS as user and group backing store.
The Solution:
There are two components that need to be present for a user to be able to access an HP-UX resource such as a file or directory, or to be able to execute an application; Authentication, and Authorization.
18 September September 2018

7. Kerberos setup /etc/krb5.conf: [libdefaults]
default_realm = WTEC.DIAGNOSTIC.HP.COM
default_tkt_enctypes = DES-CBC-MD5[1]
default_tkt_enctypes = DES-CBC-MD5
ccache_type = 2
[realms]
WTEC.DIAGNOSTIC.HP.COM = {
kdc = mccalldc.wtec.diagnostic.hp.com:88 }
[domain_realm]
.wtec.diagnostic.hp.com = WTEC.DIAGNOSTIC.HP.COM
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
Authentication First!
From a user standpoint, the credentials used for authentication are typically a username/password that proves that I am who I say I am to the system that hosts the resources I require access to. Since we are using Kerberos already as our authentication method for these Active Directory users, and HP-UX comes standard with Kerberos (at and beyond), we will take advantage of that and configure our HP-UX system to authenticate these users against the same Kerberos Distribution Center (KDC) as the existing windows servers use. There is already a great deal of information available with regard to setting up Samba on HP-UX to authenticate against an Active Directory KDC, so I will not go into too much detail here.[1] Instead, let me explain by example.
First, we will need to set up our /etc/krb5.conf file according to the information in the ‘initial conditions’ as shown in the slide above[2] .
[1] “HP CIFS Server 3.0d Administrator's Guide version A.02.02: HP-UX 11i v1 and v2”, Chapter 8
[2] I am using DES-CBC-MD5 here because that is the enctype that seems to work best if you are also using HP CIFS Server (Samba) to share out files and printers to AD users. But I’ve got encryption type DES-CBC-CRC to work and other types may work as well.
18 September September 2018

8. Verifying the kerberos setup
# kinit moby
Password for
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal:
Valid starting Expires Service principal
05/25/06 07:00:40 05/25/06 16:58:19
renew until 05/25/06 17:00:40
Next, let’s verify that we are able to get credentials from the Active Directory KDC with the kinit command.
18 September September 2018

9. Pam setup # PAM configuration[1] # Authentication management
login auth sufficient /usr/lib/security/libpam_unix.1
login auth sufficient /usr/lib/security/libpam_krb5.1
ftp auth sufficient /usr/lib/security/libpam_krb5.1
ftp auth required /usr/lib/security/libpam_unix.1
OTHER auth required /usr/lib/security/libpam_unix.1
# Account management
login account sufficient /usr/lib/security/libpam_unix.1
login account sufficient /usr/lib/security/libpam_krb5.1
ftp account sufficient /usr/lib/security/libpam_krb5.1
ftp account required /usr/lib/security/libpam_unix.1
OTHER account required /usr/lib/security/libpam_unix.1
# Session management
login session sufficient /usr/lib/security/libpam_unix.1
login session sufficient /usr/lib/security/libpam_krb5.1
OTHER session required /usr/lib/security/libpam_unix.1
# Password management
login password sufficient /usr/lib/security/libpam_unix.1
login password sufficient /usr/lib/security/libpam_krb5.1
passwd password required /usr/lib/security/libpam_unix.1
OTHER password required /usr/lib/security/libpam_unix.1
Now that we have verified our Kerberos setup, the next step is to configure HP-UX such that we can authenticate against this KDC at login time. To do this, we need to edit the /etc/pam.conf file as shown in Table 2: pam.conf. Again, details of using the libpam_krb5.1 pam module are well documented elsewhere.[1] The implementation in Table 2: pam.conf will first attempt to authenticate via a standard HP-UX /etc/passwd file and then resort to Kerberos authentication if the user is not found in the /etc/passwd file:[2]
[1] “Configuration Guide for Kerberos Client Products on HP-UX: HP-UX 11.0, 11i v1, 11i v1.6 and 11i v2”, Pam Kerberos chapter.
[2] For the purposes of this paper, I have only configured pam.conf to use Kerberos with login and ftp. Other services, such as ssh, could also be configured in a like manner.
[1] In HP-UX 11.23, change any instance of ‘libpam_krb5.1’ to ‘libpam_krb5.so.1’
18 September September 2018

10. So, can we log in yet? # telnet walnut.wtec.diagnostic.hp.com
Trying...
Connected to walnut.wtec.diagnostic.hp.com.
Escape character is '^]'.
Local flow control on
Telnet TERMINAL-SPEED option ON
HP-UX walnut B A 9000/785 (ta)
login: moby
Password:
Connection closed by foreign host.
WHY? Because HPUX needs to know how to map ‘moby’ to a uid.
We still need winbind for the authorization piece of the puzzle.
Now that I have set up pam.conf to authenticate telnet logins using Kerberos, and have verified that the user ‘moby’ CAN authenticate via Kerberos with a kinit command, I should be able to telnet into the HP-UX server, right? As the slide above shows, the answer is no.
Note that telnet accepted my username and password and authenticated me against the Active Directory KDC (otherwise I would have received another login prompt because of a bad user or password), but then immediately closed the connection. Why? [1]
The ‘why’ has to do with the second requirement for resource access on an HP-UX system. Authentication provides the information that ‘you are who you say you are’, but just exactly WHO are YOU? In HP-UX systems, WHO you are is determined by the mapping between your ‘username’ and a numeric value called a UserIDentifier (UID). In addition to that, the UID will be associated with one or more GroupIdentifiers (GID’s). In the simplest case, this mapping is provided by /etc/passwd and /etc/group. But since one of our requirements was that we did not want to have to redefine the user ‘moby’ on our HP-UX system, there is no entry for this user IN the /etc/passwd file. Without this mapping, a telnet session cannot be established.
This is where the winbind daemon comes into play. Winbind is a module supplied with the HP CIFS Server (Samba) product that maps Windows user and group Security Identifiers (SIDs) to a predefined range of HP-UX UIDs and GIDs that do NOT exist in the HP-UX system. This is what allows us to map an authenticated Windows user to a valid UID and can be used to authorize that user to access HP-UX resources on the system.
The winbind daemon works with the /etc/nsswitch.conf file and the library module libnss_winbind.1 to redirect the libc routines (like getgrent(), getpwnam(), getpwent(), etc) used to obtain UID/GID information about a user to the Active Directory server it is configured to access as the ‘backing store’ for this information. Since Windows uses SIDs instead of UIDs/GIDs, winbind creates and stores mappings between Windows SIDs obtained from the Active Directory and UIDs and GIDs used on the HP-UX system. The mechanisms behind this are explained in detail elsewhere.[2] So for the purposes of this paper, I will simply describe the steps needed to configure winbind to do its job in this situation.
[1] Normally you would use ‘try_first_pass’ on your libpam_krb5 line to keep from having to enter the password twice, but for purposes of clarity in our example here I have not implemented this.
[2] “HP CIFS Server 3.0d Administrator's Guide version A.02.02: HP-UX 11i v1 and v2”, Chapter 7
“The Official Samba-3 HOWTO and Reference Guide”, Chapter 23 (also ISBN# , publisher: Prentice-Hall)
18 September September 2018

11. Winbindd setup [global] encrypt passwords = yes
realm = WTEC.DIAGNOSTIC.HP.COM
netbios name = walnut #hpux host name
workgroup = WTEC
security = ADS
idmap uid = #range of UIDs to map to
idmap gid = #range of GIDs to map to
winbind separator = +
winbind enum users = Yes #for large AD Domains, set to NO[1]
winbind enum groups = Yes #for large AD Domains, set to NO
winbind use default domain = Yes
template shell = /usr/bin/sh #info not provided by windows
template homedir = /home/%U #info not provided by windows
This is just ONE of the many ways to set up winbindd – Other configurations include storing the winbindd uid/gid info in an LDAP backend, or automatically generating uids/gids based on a transform function involving the MS user and group sids.
The settings above will map Active Directory users to UIDS 1500 up to This UID range should not be used for ‘local’ HP-UX defined users. In addition, if there are more Active Directory users than will fit in this range (120 users), you will need to increase the range. The same applies to the idmap gid range for Active Directory Groups that will be mapped to GIDs.
The ‘template shell’ provides information to telnet/ftp that is normally obtained from /etc/passwd; since the Active Directory doesn’t supply this, we need to give it here. Note that this must be a valid shell as defined in /etc/shells, or one of the default shells as noted in man(3) getusershell.
The ‘template homedir’ will give the ‘login directory’ information to telnet/ftp, so it knows where to set the initial current working directory. The %U will be replaced by the username logging in; for instance in our case, if we login as ‘moby’, our home directory will be /home/moby. Make sure that you create home directories for users who will be coming in – otherwise they will be dropped into ‘/’. On Linux systems, you can automatically have home directories created for users with the ‘pam_mkhomedir.so’ module. This is not currently available on HP-UX.
[1] On large Active Directory Domains (1000’s of users and groups) you can set ‘winbind enum groups’ and ‘winbind enum users’ to no.
This will decrease network traffic and system load, but be aware that if you do so, programs that call getpwent() or getgrent() to
enumerate all users or groups will not return any data – programs such as ‘finger’ rely on having the full user list to function.
18 September September 2018

12. After joining the domain, configure winbind into nsswitch.conf
/etc/nsswitch.conf: #
passwd: files winbind
group: files winbind
hosts: dns files
networks: files
protocols: files
rpc: files
publickey: files
netgroup: files
automount: files
aliases: files
services: files
After you join you HP-UX system as a member of the Active Directory Domain:
# net ads join -U administrator
administrator's password:
Using short domain name -- WTEC
Joined 'WALNUT' to realm 'WTEC.DIAGNOSTIC.HP.COM‘
You’ll need to edit /etc/nsswitch.conf:
Note the change in the ‘passwd:’ and ‘group:’ lines, with the addition of ‘winbind’ in the above example [1]
[1] This will attempt to find the user/group name in /etc/passwd FIRST and then if not found will continue on to get the uid mapping from winbind. NOTE that if you have a user defined in /etc/passwd with the same name as a user in AD, this will mean that the AD user is never ‘found’, as the search will stop with the success in /etc/passwd.
18 September September 2018

13. Verify winbind, and create home dir
Verify your winbind configuration:
# startwinbind
winbindd started successfully; process ids:
# wbinfo -u|grep moby
moby 1545
create a home directory for moby:
# mkdir /home/moby
# chown moby /home/moby
# ll -d /home/moby
drwxrwxrwx 2 moby sys May 25 10:26 /home/moby
You could also use wbinfo –n moby to get the user entry.
The chown has the additional side effect of verifying that your nsswitch.conf configuration is working; if it were not, it would report that the user ‘moby’ could not be found.
Note also that you could use the chgrp ‘Domain Users’ /home/moby to set the group, although this is not strictly necessary.
18 September September 2018

14. Verify login # telnet walnut.wtec.diagnostic.hp.com Trying...
Connected to walnut.wtec.diagnostic.hp.com.
Escape character is '^]'.
Local flow control on
Telnet TERMINAL-SPEED option ON
HP-UX walnut B A 9000/785 (ta)
login: moby
Password:
Please wait...checking for disk quotas
$ pwd
/home/moby
$ touch test.txt
$ ll test.txt
-rw-rw-rw- 1 moby domain user May 25 10:30 test.txt
$ newgrp engineering
$ touch test.group.txt
$ ll test.group.txt
-rw-rw-rw- 1 moby engineering May 25 10:40 test.group.txt
NOTE: Since the primary group membership of ‘moby’ on the Active Directory is ‘domain users’, when you create a file the group ownership is ‘domain user’ – HP-UX has a display limitation of 11 characters in the ll output, so it truncates. You can use the ‘-n’ option of the ll command to see the underlying uid and gid that have been assigned by winbind to the user or group name:
$ ll -n
total 0
-rw-rw-rw May 25 10:40 test.engineeringgroup.txt
-rw-rw-rw May 25 10:30 test.txt
As you can see, the UID and GID used to define ownership of these two test files are in the range we specified in the ‘idmap uid’ and ‘idmap gid’ entries in the smb.conf file. Note also that you can use the standard HP-UX commands to change to other Active Directory groups that the user is a member of.
Finally, let’s get back to the original requirement we set, that ‘moby’ would be able to run the application ‘LabStats’, which will be set up with HP-UX permissions exclusive to this user:
$ whoami
moby
$ ll LabStats
-r-x moby domain user May 25 14:01 LabStats
$ LabStats
Woof,Woof!!!
18 September September 2018

15. Limitations Cannot access system from trusted domains
Pam kerberos doesn’t understand domain\username format
Winbind doesn’t understand kerberos upn format
samAccount name must be consistent with UPN
If you need consistent sid-uid/gid mapping on multiple HP-UX servers, will need to use ldap backend to store winbind mappings, or the idmap rid method to deterministically generate sid-uid/gid mapping
This method was designed and tested for use with a single HP-UX server joining a single Windows 2003 Active Directory Domain. It works fairly well in this limited case. There are, however, a number of issues that would need to be examined before extending this method to multiple HP-UX servers or Active Directory Domains with more complex structures such as trusts. For instance:
Winbind by default assigns UIDs and GIDs AS NEEDED, and stores the mappings in a tdb (Trivial Data Base) file, normally:
/var/opt/samba/locks/winbind_idmap.tdb
If this file is corrupted for any reason then the mapping between the SID (and thus the Active Directory user/group name) and the HP-UX UID/GIDs is lost, and cannot be reconstructed. Winbind can be configured to use a deterministic method of mapping sid to uid/gid (idmap_rid backend)[1]. This will work fine for our simple case here, but it does restrict you to a single windows domain, without the ability to take advantage of other domains trusted by your home domain. While this isn’t important to the single signon process (we can only log on users from our ‘home’ domain), you may want to be able to allow SAMBA users access to samba offered resources from trusted domains.
In Windows Active directory, it is possible to have user accounts such that the samAccountName (the ‘Domain\username’ that Winbind uses to do sid<->uid lookups) does NOT match the Kerberos upn; for instance:
upn =
samAccountName = WTEC\donm
In this case, when you logged in to HP-UX with winbind would try to lookup a samAccountName of WTEC\donmccall, and would fail (since the samAccountName of this user is actually WTEC\donm).
There has been some discussion on the Samba Technical lists of how we might address this in the future, but for now, to use this method, it is essential that your samAccountName be consistent with your Kerberos upn.
If you have more than one HP-UX server that you want to set up with this method, since the SID to UID/GID mapping is kept in a local file by default, AND the mapping is AS NEEDED, the same Active Directory User could be mapped to a DIFFERENT UID on each system. This could cause confusion if for instance NFS was used to export/mount file systems between the two boxes. Again, you can use idmap_rid backend to force determinism on the mapping between sid and uid/gid, with the same restriction to single domain functionality.
Trusted domains present a problem. You can easily extend your krb5.conf file to handle trusted domain authentication by adding the trusted domains as additional realms. For instance, assume that your default domain, WTEC, trusts the domain KATTRUST1, with a kdc named trustdc1.kattrust1.mccall.com:
[realms]
WTEC.DIAGNOSTIC.HP.COM = {
kdc = mccalldc.wtec.diagnostic.hp.com:88 }
KATTRUST1.wtec.diagnostic.hp.com = {
kdc = trustdc1.kattrust1.mccall.com:88
This will allow you to use kinit to get credentials for any user in the KATTRUST1.wtec.diagnostic.hp.com domain. However, you run into problems when you try to log in to HP-UX as a member of that domain. Consider a user ‘tester’ in this domain: .
When you get the telnet login prompt, the only way for you distinguish ‘tester’ in this domain from some user named ‘tester’ in your default domain is to fully qualify the username you supply:
Login:
When you do this, the HP-UX pam infrastructure will recognize this as a valid Kerberos username, and get the appropriate credentials from the kdc for this realm listed in the krb5.conf file, but then later on in the authorization portion of the pam processing, it will attempt to do a ‘getpwnam()’ with this fully qualified name. Since winbindd does not recognize this name format (it expects the name to be passed to it in the format: DOMAIN<winbindd separator>username), the pam system will refuse to complete the login sequence, because it cannot find a valid username <-> uid mapping.
At this time therefore, ONLY users from the default domain can login using this method. They are able to do so because since we have set the ‘winbind use default domain = yes’, we can simply provide the username to the ‘login:’ prompt and the default domain will be prepended appropriately when it is caught by the winbindd daemon to be looked up. Members of the samba team are investigating an enhancement to allow winbindd to parse fully qualified Kerberos names that may help with this in the future.
[1] HP CIFS Server (Samba) Administration guide, chapter 7.
18 September September 2018

16. Known issues
HP-UX ll listing limited to 11 display chars for user/group fields
HP-UX passwd command may fail when winbind is included in the /etc/nsswitch.conf file
Same name users in /etc/passwd and ADS can play havoc with your system accessibility!
Delays for ‘local’ user logins introduced when either winbind or kerberos unavailable
The HP-UX ‘ll’ listing has a display limit for user and group ownership of around 11 characters. Since Windows user and group names can be very long (64 characters), the names in the ll listing can be truncated, making it difficult to determine the group and user owner of a file or directory. The simple Perl script ‘WBll’ located under /opt/samba/WTEC_Support_Tools/ can help with this. See man(1) WBll for details. (I’ve included the perl program source at the end of these notes for convenience)
On some systems, the passwd command will complain because winbind is in the nsswitch.conf file. To resolve this, apply patch PHCO_33215 or its supersedents.
There are some things to consider before choosing the order of pam modules and nsswitch.conf backends
If an AD administrator uses a name that conflicts with names of HP-UX system specific UIDs such as root and winbind shows up before files in the /etc/nsswitch.conf, then anyone who logs in as ‘root’ will NOT actually have superuser access. This is because the uid assigned by winbind to the winbind user ‘root’ will NOT be UID 0. You could therefore actually LOSE administrative access to your HP-UX system. It is therefore critical to ensure that the order of authentication in /etc/pam.conf and name lookup in /etc/nsswitch.conf is consistent.
An even more insidious possibility: If you have libpam_winbind first in /etc/pam.conf, and you have ‘files’ first in /etc/nsswitch.conf, consider what would happen if an AD Administrator creates an AD user named ‘root’:
pam would authenticate via Kerberos the AD user root.
the ‘root’ user would be looked up (and FOUND) in the /etc/passwd file, and assigned the UID ‘0’. Now this ‘bogus’ root user, whose password is known only to the AD administrator has full superuser access to your HP-UX system!
Another consideration in choosing the order of pam modules and nsswitch.conf backends such as this is the delays that can be introduced with very large Active Directory databases. Authentication of local /etc/passwd entries may require Kerberos and/or winbind timeouts, causing unacceptable delays in logon for your /etc/passwd ‘local’ users.
WBll.pl :
#!/usr/local/bin/perl
# This perl script takes a single argument, a fully qualified directory
# or file path. It does not process wildcards; only one file or directory
# listing is allowed. It will use various incarnations of wbinfo to expand the
# uid and gid of a winbind owner and group on the file to give an 'll' like
# listing with a fully expanded owner and group field, to make up for the
# hpux 11 character limitation on user and group fields.
$filepath =
if(-d $filepath) {
$ll = `ll -nd $filepath`;
@ll = split(' ',$ll);
$cmd = 'll -nd '.$filepath.'|awk \'{print $3,$4}\''; }
elsif(-f $filepath)
$ll= `ll -n $filepath`;
@ll=split(' ',$ll);
$cmd = 'll -n '.$filepath.'|awk \'{print $3,$4}\'';
else
{ die "useage: WBll.pl filename\nexample: WBll.pl /var/share/file.txt\n"; }
$output = `$cmd`;
($uid,$gid) = split(' ',$output);
$uidsid= `/opt/samba/bin/wbinfo -U $uid`;
$gidsid= `/opt/samba/bin/wbinfo -G $gid`;
$username = `/opt/samba/bin/wbinfo -s $uidsid`;
$groupname = `/opt/samba/bin/wbinfo -s $gidsid`;
chop $username;chop $username;
chop $groupname;chop $groupname;
print $ll[0]," ",$ll[1]," ",$username =~ /Could not/ ? $ll[2]:$username," ",$gro
upname =~ /Could not/ ? $ll[3]:$groupname," ";
for ($i=4;$i < 10;$i++)
{ print $ll[$i]," "; }
print "\n";
18 September September 2018

17. In Conclusion A good model for very SIMPLE configurations
Allowing ADS users from a single domain to access ‘one-off’ HP-UX systems
Trusted domain and/or multi domain access is beyond the scope of this model.
ADS domains that permit userAccount names to be differerent than the principal part of the kerberos upn are not suited to this model.
Summary
There are a number of different methods available to implement ‘single sign on’ between an HP-UX system and a Microsoft Active Directory Domain. However, the majority of these either require software components not natively available on HP-UX, or Windows, or tend to be quite complex to set up and maintain. If you have a simpler scenario, for example, one or two HP-UX systems and you want to provide telnet access for existing Windows Active Directory domain users without managing two (or more) sets of user information stores, the combination of Kerberos client software and the winbind module available for all HP-UX and later servers may meet your needs with the minimum amount of complexity.
18 September September 2018