Unix Best Practices for AD Bridge
All AD Bridge Supported Operating Systems
Any time SSH is upgraded, domainjoin-cli configure --enable ssh should be run to verify the sshd_config file is set up properly to talk to AD Bridge Enterprise.
After any major system upgrade (kernel patch, OS upgrade, or similar) is performed, a full rejoin to the domain should be performed. This will verify that all OS-specific files are configured properly, resynchronize any changes to the Kerberos configuration, and will also update the operatingSystemVersion and operatingSystemServicePack values in Active Directory, so that the AD Bridge Reporting (or other reporting) system can accurately reflect the environment.
BeyondTrust suggests all vendor patches be applied per the vendor schedule.
Operating System Specific
BeyondTrust recommends that PAM support be enabled and tested with all client applications prior to installing AD Bridge Enterprise. While LAM is supported, PAM authentication provides standardized authentication across all environments, including AIX.
BeyondTrust recommends deprecating the practice of using the suroot group in favor of PAM-enabled sudo for all end-users and application owners on the AIX environment, due to difficulties managing the suroot group for AD users once AD Bridge Enterprise is installed.
For more information about sudo, please see https://www.ibm.com/developerworks/aix/library/au-sudo/index.html.
No special recommendations.
No special recommendations.
In RPM-based systems, each package owns its own PAM file, which is written, then updated by the authconfig process. Therefore, whenever authconfig, yum upgrade or similar command is run, customer should run domainjoin-cli configure --enable pam to ensure the pam_lsass.so entries are added back into the proper places in the PAM configuration. In some environments, customers schedule a background update from RHN on systems. After this background update is complete, domainjoin-cli configure --enable pam should also be run.
We recommend Solaris 10 U5 or higher. There are many fixes in U2, U4 and U5 for pthreads support, which AD Bridge uses extensively.
Large Solaris environments should take care to enable only the AD groups required for Unix file and sudo access, as Solaris 10 still has a maximum of 32 groups per user.
We recommend installing AD Bridge Enterprise on Solaris Zones individually. This gives the Unix administrator the flexibility to upgrade zones individually, separate from the upgrade state of the global zone. Additionally, since the join state is managed on a per-zone basis, the entire AD Bridge software installation can be managed together, on each individual zone.
Solaris Sparse Root zones should be managed with a whole system philosophy. Because certain files are only created in the global zone, when they are upgraded, all child zones should be upgraded at the same time as well. This is handled by the AD Bridge Enterprise installer automatically. The join state is still managed individually on each child zone. In cases where all the zones cannot be upgraded simultaneously, the non-upgradable systems must be migrated to a new host.
To achieve best performance for Kerberos SSO, we recommend SSH platforms based on OpenSSH 4.3 or higher. Sun Solaris SunSSH 1.2 and HP-UX SSH 2.0 also perform optimally.
For best performance, the AD Bridge Enterprise NssEnumerationEnabled setting (lw-config --detail NssEnumerationEnabled) should be set to false, which is not the default. Many applications make use of the getent() family of functions for PAM-based authentication (getpwent() and getgrent() in particular). For applications that claim PAM support but do not work with NssEnumerationEnabled set to false, NssEnumerationEnabled may need to be set to true.
Applications that run as a process on a host as a user ID should be run as a local service account. Users should not authenticate as these accounts, but instead use sudo or some similar process to authenticate as themselves with the authorization to run commands on behalf of the service account.
Applications that authenticate to another host as a user ID should use an application account based in AD, and managed by the customer's SOP for application or service accounts in AD.
All accounts that can be mapped back to a single person should be based in AD and not exist locally. If there is no account for this person in AD, the account should be moved to AD.