Kerberos against non-AIX systems: questions and troubleshooting information

This provides answers to questions about Kerberos clients that are using a Kerberos server on non-AIX systems.

Note: The Microsoft Active Directory Server is used in the following examples. However, these examples can also be applied to Solaris and HP systems.

As a first step in troubleshooting, make sure all of the servers and daemons are running.

Kerberos against non-AIX systems uses the syslog subsystem to write information about errors and debugging. To learn more about syslog logging, see the syslogd daemon.

How do I create an AIX® user?
Create an AIX user account (foo) by running the following command:
```
mkuser registry=KRB5files SYSTEM=KRB5files foo
```
The mkuser command creates a user on AIX. You must also create an account for the user on Windows Server Active Directory that corresponds to the AIX account. Creating a user account on Windows Server Active Directory implicitly creates the principals.
How do I remove a Kerberos authenticated user?
To remove a Kerberos authenticated user, run the following command:
```
rmuser –R KRB5files foo
```
The rmuser command removes a user from AIX. You must also remove the user from the Windows Server Active Directory by using the Windows Server user management tools.
How do I change the password of a Kerberos authenticated user?
To change the password of a Kerberos authenticated user, run the following command:
```
passwd –R KRB5files foo
```
If the KDC supports the kpasswd command, the passwd command changes the password of the Kerberos principal foo@MYREALM on the Kerberos Server.
How do I allow users to change expired passwords on the client?
To allow users to change expired passwords on the client, add the allow_expired_pwd=yes option to the methods.cfg file. When this option is set to yes, users with expired passwords are prompted to change their expired passwords. If the option is set to no or not present, the users cannot be authenticated.
```
KRB5:
   program = /usr/lib/security/KRB5
   options = authonly,allow_expired_pwd=yes
```
How do I convert an AIX user to a Kerberos authenticated user?
To convert an AIX user to a Kerberos authenticated user, do the following:
1. Verify that the user has an account on the Windows Server Active Directory by running the following command:
```
chuser registry=KRB5files SYSTEM=KRB5files foo
```
2. If the user does not have an account on Active Directory, create an account on Active Directory and set the SYSTEM and registry attributes by using the chuser command. The Active Directory account might not have the same user name as the AIX user name. If a different name is used for the AIX user name, use the auth_name attribute to map it to the Active Directory name.
```
chuser registry=KRB5files SYSTEM=KRB5files auth_name=Christopher chris
```
What do I do if the Password is forgotten?
If the password is forgotten, it must be changed by the Active Directory administrator. An AIX root user cannot set the password of an Active Directory Kerberos principal.
What is the purpose of the auth_name and auth_domain attributes?
Note: These attributes are optional. If an AIX system supports user names that are greater than eight characters long, the auth_name attribute might not be needed.

The auth_name and auth_domain attributes map AIX user names to Kerberos principal names on the KDC. For example, if the AIX user, chris, has the attributes auth_name=christopher and auth_domain=SOMEREALM, then the Kerberos principal name is christopher@SOMEREALM. By using the auth_domain attribute, requests are sent to the SOMEREALM realm name instead of the default realm name. This allows the user chris to authenticate to the SOMEREALM realm instead of to the MYREALM realm. In this example, the krb5.conf file must also be modified to include the SOMEREALM realm name.
Can a Kerberos-authenticated user be authenticated by using standard AIX authentication?
Yes, a Kerberos-authenticated user can be authenticated with standard AIX authentication by doing the following:
1. Set the AIX password (/etc/security/passwd) using the passwd command:
```
passwd -R files foo
```
2. Change the user's registry and SYSTEM attributes, as follows:
```
chuser -R KRB5files registry=files SYSTEM=compat foo
```
  This command changes authentication from Kerberos to compat (which uses the crypt subroutine). The next time a login is attempted by user foo, the local password from the /etc/security/passwd file is used.
  You can also use crypt authentication as a backup mechanism by changing the SYSTEM attribute to allow local authentication when Kerberos authentication fails, as follows:
```
chuser -R KRB5files SYSTEM="KRB5files or compat" foo
```
Do I Need to set up a Kerberos server on AIX when I use Windows Server 2000 Kerberos Service?
No, you do not need to configure the a Kerberos server (KDC) on an AIX client because users are authenticating against an Active Directory KDC. If you plan to use AIX Network Authentication Service KDC as the Kerberos server for some other purpose, then the Kerberos server must be configured.
What should I do if AIX does not accept my password?
If AIX does not accept your password, do the following:
- Ensure that the client is communicating with the Windows 2000 Active Directory Server
- Ensure that the password meets the requirements of both AIX and Windows Server 2000 Active Directory. Refer to Change Show Policy for information about changing password policy rules on AIX.
Note: You cannot change the password for Windows Server 2003 Kerberos Service.
What should I do if I cannot log into the system?
If you cannot log into the system, do the following:
- On a Windows system, verify that the KDC is running by doing the following:
  1. In the Control Panel, select Administrative Tools icon.
  2. Select the Services icon.
  3. Verify that the Kerberos Key Distribution Center is in the started state.
- On an AIX system, verify that the /etc/krb5/krb5.conf file points to the correct KDC, and that it has valid parameters.
- On an AIX system, verify that client-keytab file contains the host key. For example, if the default keytab file is /etc/krb5/krb5.keytab, run the following:
```
ktutil
rkt /etc/krb5/krb5.keytab
l
```
- Verify that the output of the kvno command that is in the keytab file matches the output from the Ktpass command.
- Verify that, if auth_name and auth_domain attributes are set, they refer to a valid principal name on the Active Directory KDC.
- Verify that the SYSTEM attribute is set for Kerberos login.
- Verify that the password is not expired.
How can I disable ticket-granting ticket verification?
You can disable ticket-granting ticket verification by specifying an option in the /usr/lib/security/methods.cfg file under the KRB5 stanza as follows:
```
KRB5:
   program = /usr/lib/security/KRB5
   options = tgt_verify=no
KRB5files:
   options = db=BUILTIN,auth=KRB5
```
The possible values for the tgt_verify option are no or false for disabling ticket-granting ticket verification, and yes or true for enabling ticket-granting ticket verification. By default, the ticket-granting ticket verification is enabled. When you set the tgt_verify option to no, the ticket-granting ticket verification is disabled, and you do not need to transfer the host-principal keys. This change only eliminates the need of the keytab file for authentication purposes. Other Kerberos-enabled applications may require the keytab file for host and service principals.
What should I do if I cannot log in because a host name does not resolve and the fully-qualified host name fails?
The ticket-granting ticket verification requires that a host/<host_name> principal is created on the KDC. This host name is the fully qualified name of the client where authentication is performed. The client system requests a service ticket by using the host principal name host/<host_name>. In some configurations, the client machine is unable to obtain the fully-qualified host name and instead, it gets a short name. In such instances, a mismatch occurs, the ticket-granting ticket verification fails, and the login fails. For example, if /etc/hosts has only the short name and the /etc/netsvc.conf file specifies hosts=local,bind, then the name resolution returns the short name.
To correct name-resolution problems, do one of the following:
- Modify the name-resolution order in the /etc/netsvc.conf file so that the fully-qualified host name is returned. The netsvc.conf file specifies the sequential order for resolving host names and aliases.
  In the following example, the resolver uses the BIND service to resolve the host name. If BIND service fails, the resolver uses the /etc/hosts file. If both methods fail, the resolvers use nis.
```
hosts=bind,local,nis
```
  If the first method used in the search order must be local, change the short name (myhost) in the /etc/hosts file to a fully-qualified host name (myhost.austin.ibm.com).
- If the ticket-granting ticket verification is not required, you can find instructions for disabling ticket-granting ticket verification in How can I disable ticket-granting ticket verification?.
Why does the passwdexpired subroutine return 0 when the kerberos user password is expired on the non-AIX kerberos server?
The passwdexpired subroutine returns 0 because the password expiration information cannot be obtained directly from the non-AIX kerberos server due to incompatibility or unavailability of the kadmin interfaces.

The allow_expired_pwd flag in the methods.cfg file enables AIX to get the password expiration information using the kerberos authentication interfaces. The actual status of the password expiration information is obtained either during the login or by calling the authenticate subroutine and the passwdexpired subroutine.