Skip Navigation Links | |
Exit Print View | |
![]() |
System Administration Guide: Security Services Oracle Solaris 10 8/11 Information Library |
1. Security Services (Overview)
Part II System, File, and Device Security
2. Managing Machine Security (Overview)
3. Controlling Access to Systems (Tasks)
4. Controlling Access to Devices (Tasks)
5. Using the Basic Audit Reporting Tool (Tasks)
6. Controlling Access to Files (Tasks)
7. Using the Automated Security Enhancement Tool (Tasks)
Part III Roles, Rights Profiles, and Privileges
8. Using Roles and Privileges (Overview)
9. Using Role-Based Access Control (Tasks)
10. Role-Based Access Control (Reference)
Part IV Cryptographic Services
13. Oracle Solaris Cryptographic Framework (Overview)
14. Oracle Solaris Cryptographic Framework (Tasks)
15. Oracle Solaris Key Management Framework
Part V Authentication Services and Secure Communication
16. Using Authentication Services (Tasks)
19. Using Oracle Solaris Secure Shell (Tasks)
20. Oracle Solaris Secure Shell (Reference)
21. Introduction to the Kerberos Service
22. Planning for the Kerberos Service
23. Configuring the Kerberos Service (Tasks)
24. Kerberos Error Messages and Troubleshooting
Common Kerberos Error Messages (A-M)
Common Kerberos Error Messages (N-Z)
Problems With the Format of the krb5.conf File
Problems Propagating the Kerberos Database
Problems Mounting a Kerberized NFS File System
25. Administering Kerberos Principals and Policies (Tasks)
26. Using Kerberos Applications (Tasks)
27. The Kerberos Service (Reference)
Part VII Oracle Solaris Auditing
28. Oracle Solaris Auditing (Overview)
29. Planning for Oracle Solaris Auditing
30. Managing Oracle Solaris Auditing (Tasks)
This section provides troubleshooting information for the Kerberos software.
If the krb5.conf file is not formatted properly, then the following error message maybe displayed to the terminal or the log file:
Improper format of Kerberos configuration file while initializing krb5 library
If there is a problem with the format of the krb5.conf file, then the associated services could be vulnerable to attack. You should fix the problem before you allow Kerberos features to be used.
If propagating the Kerberos database fails, try /usr/bin/rlogin -x between the slave KDC and master KDC, and from the master KDC to the slave KDC server.
If the KDCs have been set up to restrict access, rlogin is disabled and cannot be used to troubleshoot this problem. To enable rlogin on a KDC, you must enable the eklogin service.
# svcadm enable svc:/network/login:eklogin
After you finish troubleshooting the problem, you need to disable the eklogin service..
If rlogin does not work, problems are likely because of the keytab files on the KDCs. If rlogin does work, the problem is not in the keytab file or the name service, because rlogin and the propagation software use the same host/host-name principal. In this case, make sure that the kpropd.acl file is correct.
If mounting a Kerberized NFS file system fails, make sure that the /var/rcache/root file exists on the NFS server. If the file system is not owned by root, remove it and try the mount again.
If you have a problem accessing a Kerberized NFS file system, make sure that the gssd service is enabled on your system and the NFS server.
If you see either the invalid argument or bad directory error message when you are trying to access a Kerberized NFS file system, the problem might be that you are not using a fully qualified DNS name when you are trying to mount the NFS file system. The host that is being mounted is not the same as the host name part of the service principal in the server's keytab file.
This problem might also occur if your server has multiple Ethernet interfaces, and you have set up DNS to use a “name per interface” scheme instead of a “multiple address records per host” scheme. For the Kerberos service, you should set up multiple address records per host as followsKen Hornstein, “Kerberos FAQ,” [http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#kerbdns], accessed 10 March 2010.:
my.host.name. A 1.2.3.4 A 1.2.4.4 A 1.2.5.4 my-en0.host.name. A 1.2.3.4 my-en1.host.name. A 1.2.4.4 my-en2.host.name. A 1.2.5.4 4.3.2.1 PTR my.host.name. 4.4.2.1 PTR my.host.name. 4.5.2.1 PTR my.host.name.
In this example, the setup allows one reference to the different interfaces and a single service principal instead of three service principals in the server's keytab file.
If authentication fails when you try to become superuser on your system and you have already added the root principal to your host's keytab file, there are two potential problems to check. First, make sure that the root principal in the keytab file has a fully qualified host name as its instance. If it does, check the /etc/resolv.conf file to make sure that the system is correctly set up as a DNS client.
To be able to monitor the credential mappings, first uncomment this line from the /etc/gss/gsscred.conf file.
SYSLOG_UID_MAPPING=yes
Next instruct the gssd service to get information from the /etc/gss/gsscred.conf file.
# pkill -HUP gssd
Now you should be able to monitor the credential mappings as gssd requests them. The mappings are recorded by syslogd, if the syslog.conf file is configured for the auth system facility with the debug severity level.