zaterdag 31 juli 2010

AIX : Cross realm Kerberos TGT verification does not work

Introduction

Currently, the AIX Kerberos load module KRB5 cannot handle cross realm Ticket Granting Ticket verification.

Details

Assume the following setup:
- An Active Directory domain ABC.COM which contains all user principals.
- A Kerberos/NAS realm XYZ.COM which contains all service principals, including host service principals.
- Active Directory user foo which is mapped to AIX user foo using the following generic mapping rule in krb5.conf
      auth_to_local = RULE:[1:$1@$0](.*@ABC.COM)s/@.*//
- The default Kerberos realm in krb5.conf is XYZ.COM
- The AIX user foo has the following properties:
      - SYSTEM=KRB5, which identifies that the Kerberos load module KRB5 needs to be used for authentication
      - auth_domain=ABC.COM, which identifies that an Active Directory KDC in domain ABC.COM should be contacted for authentication. This information is present in the [realms] section of krb5.conf.

By default, the following Kerberos authentication flow is followed when Active Directory user foo wishes to connect to AIX host bar.xyz.com:

- The KRB5 load module on bar.xyz.com sends an AS-REQ message to a KDC in Active Directory domain ABC.COM. This is regulated by the auth_domain user attribute of the local AIX user foo to which foo@ABC.COM is mapped using the auth_to_local rule. If auth_domain isn't set, the default realm in krb5.conf is used.
- The Active Directory KDC returns the AS-REQ message to bar.xyz.com, containing the TGT and TGS session key.
- Now bar.xyz.com needs to verify that the TGT is genuine by actually using it to see if it can access services locally with it. The idea behind this is that only the "real" KDC would be able to produce a valid service ticket, encrypted with the service's private key. In order to perform this TGT verification, a keytab must be installed on bar.xyz.com which contains the host/bar.xyz.com@XYZ.COM host service principal. This keytab contains the secret key of the host service principal, only known to the TGS and the service itself.

Apparently, the KRB5 load module sends the TGT verification TGS-REQ message to the Active Directory KDC in ABC.COM instead of to the NAS KDC in XYZ.COM, which contains the service principal. Since the Active Directory KDC does not know the host/bar.xyz.com@ABC.COM host service principal, it will return KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN, resulting in user authentication failure. The problem lies in the fact that the KRB5 Kerberos load module was never designed to handle cross realm authentication properly. Therefore, the TGT verification code does not use the krb5_verify_init_creds() call.

Solution

- Disable TGT verification in /usr/lib/security/methods.cfg
     KRB5:
           program = /usr/lib/security/KRB5
           program_64 = /usr/lib/security/KRB5_64
           options = authonly,tgt_verify=no


- A DCR was created and accepted for this issue, which should be fixed in AIX 6.1 TL6 and AIX 7.1.
DCR MR082009165 : TGT verification for user defined on a KDC does not work when host principals are defined on a different KDC in a cross realm setup.
APAR IZ78593 : ENABLE CROSS REALM TGT VERIFICATION IN KRB5A

Note: Starting AIX 6.1 TL2, the KRB5A and KRB5 load modules have been merged. APAR IZ26224 addresses this.

donderdag 22 juli 2010

VIO : Change default value of hcheck_interval

Currently, the default value of hcheck_interval for VSCSI hdisks is set to 0, meaning that healthchecking is disabled. The hcheck_interval attribute of a hdisk can only be changed online if the volume group to which the hdisk belongs, is not active. If the volume group is active, the ODM value of the hcheck_interval can be altered in the CuAt class, as shown in the following example:

chdev -l hdisk0 -a hcheck_interval=60 -P

The change will then be applied once the system is rebooted. However, it is possible to change the default value of the hcheck_interval attribute in the PdAt ODM class. As a result, you won't have to worry about its value anymore and newly discovered hdisks will automatically get the new default value, as illustrated in the example below:

odmget -q 'attribute = hcheck_interval AND uniquetype = "PCM/friend/vscsi"' PdAt | sed 's/deflt = "0"/deflt = "60"/' | odmchange -o PdAt -q 'attribute = hcheck_interval AND uniquetype = "PCM/friend/vscsi"'

woensdag 21 juli 2010

AIX : Examining ulimits of running process

Currently, AIX does not allow to examine the ulimits of a running process through the /proc file system. F.e. in Linux this is possible, as shown in the following example:

# cat /proc/4121/limits
LimitSoft LimitHard LimitUnits
Max cpu timeunlimitedunlimitedms
Max file sizeunlimitedunlimitedbytes
Max data sizeunlimitedunlimitedbytes
Max stack size8388608unlimitedbytes
Max core file sizeulimitedunlimitedbytes
Max resident setunlimitedunlimitedbytes
. . .

The only alternative currently available in AIX is to use dbx and attach to the running process, as shown in the following example:

# dbx -a 700464
(dbx) proc rlimit
rlimit namerlimit_currlimit_max(units)
RLIMIT_CPU:(unlimited)(unlimited)sec
RLIMIT_FSIZE:(unlimited)(unlimited)bytes
RLIMIT_DATA:67108864100663296bytes
RLIMIT_STACK:335544324294967296bytes
RLIMIT_CORE:(unlimited)(unlimited)bytes
RLIMIT_RSS:(unlimited)(unlimited)bytes
. . .
(dbx) quit

The only major drawback from this alternative is that dbx interrupts the process by sending a SIGTRAP signal. After the dbx sessions finishes, the process terminates. A Design Change Request was made to address this.