Basic troubleshooting for the AD Bridge agent
The following are basic steps for troubleshooting issues related to the AD Bridge agent.
Check the version and build number
You can check the version and build number of the AD Bridge agent from computers that are running Linux or Unix, or from a computer that is connected to the domain controller and is running Windows.
Check from Linux or Unix
To check the version number of the AD Bridge agent from a computer running Linux or Unix, execute the following command:
cat /opt/pbis/data/ENTERPRISE_VERSION
Another option is to execute the following command:
/opt/pbis/bin/get-status
Check the build number of the agent
On Linux distributions that support RPM, for example, Red Hat Enterprise Linux, Fedora, SUSE Linux Enterprise, OpenSUSE, and CentOS, you can determine the version and build number of the agent (10.1.0.xxxx in the examples below) by executing the following command at the shell prompt:
rpm -qa | grep pbis
The result shows the build version after the version number:
pbis-enterprise-10.1.0-881.x86_64
On Unix computers and Linux distributions that do not support RPM, the command to check the build number varies by platform:
Platform | Command |
---|---|
Debian and Ubuntu | dpkg –S /opt/pbis/ |
Solaris | pkginfo | grep -i pbis |
AIX | lslpp –l | grep pbis |
Check from Windows
To check the version and build number of the AD Bridge agent from a Windows administration workstation that is connected to your domain controller:
In Active Directory Users and Computers, right-click the Linux or Unix computer that you want, and then click Properties.
Click the Operating System tab. The build number is shown in the Service pack box.
Determine a computer's FQDN
You can determine the fully qualified domain name of a computer running Linux or Unix by executing the following command at the shell prompt:
ping -c 1 `hostname`
On Solaris
On Sun Solaris, you can find the FQDN by executing the following command (the computer's configuration can affect the results):
FQDN=`/ usr/lib/mail/ sh/ check-hostname|cut - d" " -f7`;echo $FQDN
Note
For more information, see Join Active Directory without changing /etc/hosts
Ensure outbound ports are open
If you are using local firewall settings, such as iptables, on a computer running the AD Bridge agent, make sure the following ports are open for outbound traffic.
Note
The AD Bridge agent is a client only; it does not listen on any ports.
Port | Protocol | Use |
---|---|---|
53 | UDP/ TCP | DNS |
88 | UDP/TCP | Kerberos 5 |
123 | UDP | NTP |
389 | UDP/TCP | LDAP |
445 | TCP | SMB over TCP |
464 | UDP/TCP | Computer password changes (typically after 30 days) |
1433 | TCP | Connection to SQL Server. Open the port you are using. The default port for SQL is 1433. |
3268 | TCP | Global Catalog search |
Note
To view the firewall rules on a Linux computer using iptables, execute the following command:
iptables - nL
Check the file permissions of nsswitch.conf
For AD Bridge to work correctly, the /etc/nsswitch.conf file must be readable by user, group, and world. The following symptoms indicate that you should check the permissions of nsswitch.conf:
- Running the id command with an AD account as the argument (for example, id example.com\\kathy) works when it is executed as root, but when the same command is executed by the AD user, it returns only a UID and GID without a name.
- You receive an I have no name! or intruder alert error message for non-root users.
Configure SSH after upgrading it
After SSH is upgraded, run the following command as root to make sure that the sshd_config file is set up properly to work with AD Bridge:
domainjoin-cli configure --enable ssh
Upgrade an operating system
After upgrading an operating system or installing a kernel patch, you should rerun the domain-join command to:
- Make sure that the files related to the operating system, such as PAM and nsswitch, are configured properly to work with AD Bridge.
- Update the operatingSystemVersion value and the operatingSystemServicePack value in Active Directory so the AD Bridge reporting tool reflects the correct version numbers.
Another suggestion, nearly universal in scope, is to apply updates to test systems before you apply updates to production systems, giving you the opportunity to identify and resolve potential issues before they can affect production machines.
Updated 16 days ago