Perform OS-Specific Troubleshooting
The following topics provide AD Bridge Enterprise agent troubleshooting guidance that is unique to individual operating systems.
The following procedures may help resolve issues with the AD Bridge Enterprise agent on computers running the Red Hat or CentOS operating systems.
Modify PAM to Handle UIDs Less than 500
By default, the configuration file for PAM system authentication, /etc/pam.d/system-auth, on Red Hat Enterprise Linux 5 and CentOS 5 contains the following line, which blocks a user with a UID value less than or equal to 500 from logging on to a computer running the AD Bridge Enterprise agent. The symptom is a login failure with a never-ending password prompt.
auth requisite pam_succeed_if.so uid >= 500 quiet
Solution: Either delete the line from /etc/pam.d/system-auth or modify it to allow users with UIDs lower than 500:
auth requisite pam_succeed_if.so uid >= 50 quiet
Ensure That the Correct Version of the coreutils RPM Is Installed
Some patch levels of the coreutils RPM on Red Hat Enterprise Linux 3 have a version of the id command that does not return complete group membership information when the command is run with the id username syntax. The command returns only the UID and primary GID for a user. Secondary groups may be omitted.
On Linux, there are four commands to get group memberships:
- Call getgroups. It returns the primary and secondary GIDs of the current process. The id command calls this when a username is not passed.
- Call initgroups followed by getgroups. The initgroups call will query nsswitch for the users primary and secondary groups. The result is stored in the process, which is then returned by getgroups. You need root access to call initgroups, so id sometimes does this when you run the command as root.
- Call getgrouplist. This function calls nsswitch to return the group list of a user, and it does not require root access. Unfortunately this function was added in glibc 2.2.4, and the id command started using it after that.
- Call getgrent to enumerate all the groups on the system, and search for the user in the gr_mem field.
On RHEL 3, id from coreutils version 4.5.3-28.4 can use the getgrouplist function, but that code was removed in 4.5.3-28.7. To check your coreutils version for glibc:
rpm -q coreutils glibc coreutils-4.5.3-28.7 glibc-2.3.2-95.50
Without the getgrouplist function, the id command falls back on using getgrent to get the groups. By default, AD Bridge Enterprise returns abbreviated results when enumerating all groups, so id does not find the user in the member's field. You could turn on full group enumeration, but then the id command would download the group membership of everyone in Active Directory just to obtain the results for one user.
Here is an example.
Check the user.
[root@example-03293b root]# su - corpqa\\user0001 [CORPQA\user0001@example-03293b user0001]$ id CORPQA\\user0002 uid=105559(CORPQA\user0002) gid=1661993473(CORPQA\domain^users) groups=1661993473 (CORPQA\domain^users) [CORPQA\user0001@example-03293b user0001]$ logout
Turn on full group enumeration locally by using config.
[root@example-03293b root]# /opt/pbis/bin/config NssGroupMembersQueryCacheOnly false [root@example-03293b root]# /opt/pbis/bin/config NssEnumerationEnabled true
Check the user again:
[root@example-03293b root]# su - corpqa\\user0001 [CORPQA\user0001@example-03293b user0001]$ id CORPQA\\user0002 uid=105559(CORPQA\user0002) gid=1661993473(CORPQA\domain^users) groups=1661993473(CORPQA\domain^users),1662020290(CORPQA\enabled), 1662020291(CORPQA\enabledparent),100395(CORPQA\innergroup1), 100401(CORPQA\loopgroup),100394(CORPQA\outergroup), 100381(CORPQA\usergroup0001),100382(CORPQA\usergroup0002), 1662002383(CORPQA\usergroup0009),1662002420(CORPQA\usergroup0047), 1662003573(CORPQA\usergroup0200)
Even with NSS settings enabled, the id command does a case-sensitive search even though AD Bridge Enterprise does not treat the usernames as case sensitive. Therefore, if you use the non-canonical case, the groups are not displayed.
To fix the output of the id command on RHEL 3 computers where this problem occurs, ensure that the correct version of the coreutils RPM is installed.
SUSE Linux Enterprise Desktop (SLED)
Review the following sections to fix SUSE issues.
Home Directory on SLED 11
When a user gains access to SLED 11 through Nomad, a remote desktop using RDP protocol with session management, the default home directory specified in /lib/security/pam_lsass.so is ignored.
To correct the issue, change /etc/pam.d/xrdp-sesman to include the following line:
session sufficient /lib/security/pam_lsass.so
Update PAM on SLED 11
Novell has issued a PAM update (pam-config-0.68-1.22) for SLED 11 that modifies the common-session-pc file to include the following entry:
session optional pam_gnome_keyring.so auto_start_if=gdm
Because the PAM update makes a backup of the file and replaces it with the modified version, the changes that AD Bridge had made to the file are no longer present, which blocks new AD users from logging on. The similar error message may appear:
Could not update ICEauthority file /home/john/.ICEauthority There is a problem with the configuration server. (/user/lib/gconf/2/gconf-sanity-check-2 exited with status 256)
Solution: After you update PAM, run the following command as root:
/opt/pbis/bin/domainjoin-cli configure --enable pam
Or, you can make the changes manually. Open the backed up version of the common-session-pc file, add the following line to it, and then use it to overwrite the new version of the common-session-pc file:
session optional pam_gnome_keyring.so auto_start_if=gdm
Try the following to resolve issues with the AD Bridge Enterprise agent on computers running AIX.
Increase Max Username Length on AIX
By default, AIX is not configured to support long user and group names, which might present a conflict when you try to log on with a long Active Directory username. On AIX 5.3 and AIX 6.1, the symptom is that group names, when enumerated through the groups command, are truncated.
To increase the max username length on AIX 5.3, use the following syntax:
# chdev -l sys0 -a max_logname=MaxUserNameLength+1
# chdev -l sys0 -a max_logname=255
This command allocates 254 characters for the user and 1 for the terminating null.
The safest value to which you can set max_logname is 255.
You must reboot for the changes to take effect:
# shutdown –Fr
AIX 5.2 does not support increasing the maximum user name length.
When you update AIX, the authentication of users, groups, and computers might fail because the AIX upgrade process overwrites changes that AD Bridge makes to system files. Specifically, upgrading AIX to version 6.1tl3 overwrites /lib/security/methods.cfg, so you must manually add the following code to the last lines of the file after you finish upgrading:
LSASS: program = /usr/lib/security/LSASS
Try the following to resolve issues with the AD Bridge agent on computers running FreeBSD.
Keep Usernames to 16 Characters or Less
On FreeBSD, user names that are longer than 16 characters, including the domain name, exceed the FreeBSD username length limit. Attempts to connect by ssh, for example, to a FreeBSD computer with a user name that exceeds the limit can result in the following notification:
bvt-fbs72-64# ssh testuser1@localhost Password: Connection to localhost closed by remote host. Connection to localhost closed.
The log for sshd, meanwhile, might show an error that looks something like this:
Oct 7 18:22:57 vermont02 sshd: setlogin(EXAMPLE\adm.kathy): Invalid argument Oct 7 18:25:02 vermont02 sshd: setlogin(EXAMPLE\adm.kathy): Invalid argument
Although testuser1 is less than 16 characters, when you use the id command to check the account, something longer than 16 characters is returned:
[root@bvt-fbs72-64 /home/testuser]# id testuser1 uid=1100(BVT-FBS72-64\testuser1) gid=1801(BVT-FBS72-64\testgrp) groups=1801(BVT-FBS72-64\testgrp)
The result of the id command exceeds the FreeBSD username length limit.
There are several solutions: set the default domain, change the user name to 16 characters or less, or with AD Bridge use aliases. Keep in mind, though, that aliases will not solve the problem in relation to the AD Bridge local provider.
Try the following to resolve issues with the AD Bridge agent on computers running Solaris.
Turn On Core Dumps on Solaris 10
If you are investigating a process that is crashing on Solaris 10 or Solaris Sparc 10, but a core dump is not being generated, it's probably because per-process core dumps are turned off. You can use the coreadm command to manage the core dumps. The settings are saved in the /etc/coreadm.conf file.
A configuration for core dumps with the per-process option turned off looks like this:
# coreadm global core file pattern: global core file content: default init core file pattern: core init core file content: default global core dumps: disabled per-process core dumps: disabled global setid core dumps: disabled per-process setid core dumps: disabled global core dump logging: disabled
You need per-process core dumps to troubleshoot a process that is terminating unexpectedly. To turn on core dumps for a process, execute the following command as root:
coreadm -e process
For more information, please see Core Dump Management on the Solaris OS and the man page for coreadm.