This article applies to BoKS 6.7 and 7.0.


  1. BoKS AD bridge was designed for a one-to-one mapping between each AD user account and BoKS UNIX user account.
  2. Changing the Host Group membership for an AD account was not reflected in BoKS.
  3. (From HFBM-0048) Unless ALLOWUIDCHANGE is set to ``y´´ in $BOKS_etc/adsync.cfg, changes in AD that would affect the login name for an account in BoKS were not reflected in BoKS.
  4. The adgroup command did not exit with non-zero status in all cases. This could cause adsync to delete all users.

Resolution / Workaround

Apply hotfix HFBM-0070 (for BoKS Manager 6.7) or HFBM-0085 (for BoKS Manager 7.0), available for download from the HelpSystems Community Portal.

  1. A redesign now allows an AD account to map to multiple BoKS accounts (both UNIX and WINDOM type of users) by letting the AD account be a member of multiple Host Groups exported from BoKS.
  2. adsync has been modified so if Host Group membership is changed in AD, this is reflected in BoKS by deleting and re-creating the account(s).
  3. adsync has been modified to allow changes to login name if ALLOWUIDCHANGE=y.
  4. adgroup will now exit with non-zero status on errors. Additionally adsync has been modified to abort if adgroup fails to retrieve Host Groups.

Additionally this contains a correction for adgetdc which could cause it to abort if e.g. DNS lookup of an AD server failed. (A similar problem exists in adjoin and is corrected by hotfix HFBM-0069).

Modified listings:
- mapkerberos -l
Now lists three columns: Principal, BoKS user and Account type.

- lsbks -a/-f
Parameter "Has same User Principal Name as:" now lists multiple lines of users if more than two users share the same principal name.

- lsbks -DA
Displays comma-separated list of users with the same principal name.


The redesign involves a small change to the database schema (a key is no longer required to be unique). This means this hotfix MUST be installed on the Master and all Replicas before adsync is executed.

This also means that the kerberos-to-user mapping table (T68) should be empty or at least not contain any duplicate keys (the PRINCIPAL field) before the hotfix is uninstalled.

Still have questions? We can help. Submit a case to Technical Support.

Last Modified On: May 25, 2018