Accounts and attributes

The following topics provide help with troubleshooting account issues.

Allow access to account attributes

AD Bridge is compatible with Small Business Server 2003. However, because the server locks down several user account values by default, you must create a group in Active Directory for your Unix computers, add each AD Bridge client computer to it, and configure the group to read all user information.

On other versions of Windows Server, the user account values are available by default. If, however, you use an AD security setting to lock them down, they will be unavailable to the AD Bridge agent.

To find Unix account information, the AD Bridge agent requires that the AD computer account for the machine running AD Bridge can access the attributes in the following table.

To allow access to account attributes:

1. In Active Directory Users and Computers, create a group named Unix Computers.
2. Add each AD Bridge client computer to the group.
3. In the console tree, right-click the domain, choose Delegate Control, click Next, click Add, and then enter the group named Unix Computers.
4. Click Next, select Delegate the following common tasks, and then in the list select Read all user information.
5. Click Next, and then click Finish.
6. On the target Linux or Unix computer, restart the AD Bridge agent to reinitialize the computer account’s logon to Active Directory and to get the new information about group membership.
7. Run /opt/pbis/enum-users to verify that you can read user information.

ℹ️

Note

For more information, see Storage Modes in the Install AD Bridge.

User settings are not displayed in ADUC

If there is no group in a cell that can serve as the user's primary GID, for instance, because the default primary group, domain users, has been removed from the cell, the AD Bridge Cell Settings tab for a user in Active Directory Users and Computers (ADUC) will not display the user or group settings, as shown in the screen shot below.

To display the settings, enable a group that the user is a member of.

Enable logging for ADUC plugin

Log files can be generated to troubleshoot issues with the ADUC AD Bridge Cell Settings tab.

By default, there is no log file generated unless the following environment variable is set: ENABLE_PBISUILOG=true

Set the variable in Control Panel > System > Advanced System Settings > Advanced > Environment Variables.

After the setting is turned on, log files are generated the next time ADUC starts. Logs are saved in the C:\Users\username\AppData\Local\PBIS.Logs directory. The plugin displays a dialog box containing the log file path when it opens the log file.

Resolve an AD alias conflict with a local account

When you use AD Bridge to set an Active Directory alias for a user, the user can have a file-ownership conflict under the following conditions if the user logs on with the AD account:

• The AD alias is the same alias as the original local account name.
• The home directory assigned to the user in Active Directory is the same as the local user's home directory.
• The owner UID-GID of the AD account is different from that of the local account.

To avoid such conflicts, by default AD Bridge includes the short AD domain name in each user's home directory. If the conflict nevertheless occurs, there are two options to resolve it:

• Make sure that the UID assigned to the user's AD alias is the same as that of the user's local account.
• Log on as root and use the chown command to recursively change the ownership of the local account's resources to the AD user alias.

Change ownership

Log on the computer as root and execute the following commands:

cd <users home directory root>
chown –R <AD user UID>:<AD primary group ID> *.*

Alternatively, the following command may be used:

chown –R <short domain name>\\<account name>:<short domain name>\\<AD group name> *.*

ℹ️

Note

You can generate reports to help identify duplicates and inconsistencies.

Fix the shell and home directory paths

Symptom: A local directory is in the home directory path and the home directory path does not match the path specified in Active Directory or in /etc/passwd.

Example: /home/local/DOMAIN/USER instead of /home/DOMAIN/USER

The shell might also be different from what is set in Active Directory, for example, /bin/ksh instead of /bin/bash.

Problem: The computer is not in an AD Bridge Cell in Active Directory.

Solution: Make sure the computer is in an AD Bridge Cell.

ℹ️

Note

For more information, see What are AD Bridge Cells?.

A Default Cell handles mapping for computers that are not in an OU with an associated cell. The Default Cell can contain the mapping information for all your Linux and Unix computers. For instance, a Linux or Unix computer can be a member of an OU that does not have a cell associated with it. In such a case, the home directory and shell settings are obtained from the nearest parent cell or the Default Cell. If there is no parent cell and no Default Cell, the computer will not receive its shell and home directory paths from Active Directory.

Troubleshoot with the get-status command

The /opt/pbis/bin/get-status command shows whether the domain or the AD Bridge AD provider is offline. The results of the command include information useful for general troubleshooting.

/opt/pbis/bin/get-status

✅

Example

Here is an example of the information the command returns:

[root@rhel5d bin]# /opt/pbis/bin/get-status
LSA Server Status:
Compiled daemon version: 6.1.272.54796
Packaged product version: 6.1.272.54796
Uptime:        15 days 21 hours 24 minutes 1 seconds

[Authentication provider: lsa-activedirectory-provider]

        Status:        Online
        Mode:          Un-provisioned
        Domain:        EXAMPLE.COM
        Forest:        example.com
        Site:          Default-First-Site-Name
        Online check interval:  300 seconds
        [Trusted Domains: 1]

        [Domain: EXAMPLE]

                DNS Domain:       example.com
                Netbios name:     EXAMPLE
                Forest name:      example.com
                Trustee DNS name: 
                Client site name: Default-First-Site-Name
                Domain SID:       S-1-5-21-3190566242-1409930201-3490955248
                Domain GUID:      71c19eb5-1835-f345-ba15-0595fb5b62e3
                Trust Flags:      [0x000d]
                                  [0x0001 - In forest]
                                  [0x0004 - Tree root]
                                  [0x0008 - Primary]
                Trust type:       Up Level
                Trust Attributes: [0x0000]
                Trust Direction:  Primary Domain
                Trust Mode:       In my forest Trust (MFT)
                Domain flags:     [0x0001]
                                  [0x0001 - Primary]

                [Domain Controller (DC) Information]

                        DC Name:              w2k3-r2.example.com
                        DC Address:           192.168.92.20
                        DC Site:              Default-First-Site-Name
                        DC Flags:             [0x000003fd]
                        DC Is PDC:            yes
                        DC is time server:    yes
                        DC has writeable DS:  yes
                        DC is Global Catalog: yes
                        DC is running KDC:    yes

[Authentication provider: lsa-local-provider]

        Status:        Online
        Mode:          Local system
        Domain:        RHEL5D

Troubleshoot user rights with Ldp.exe and Group Policy modeling

The following Microsoft default domain policy and default domain controller policy can cause an AD Bridge client to fail to join a domain or to fail to enumerate trusts:

• Access this computer from the network: Users and computers that interact with remote domain controllers require the Access this computer from the network user right. Users, computers, and service accounts can lose the user right by being removed from a security group that has been granted the right. Removing the administrators group or the authenticated users group from the policy setting can cause domain join to fail. According to Microsoft, There is no valid reason for removing Enterprise Domain Controllers group from this user right.

ℹ️

Note

For more information, see Microsoft article 823659.

• Deny access to this computer from the network: Including the domain computers group in the policy setting, for instance, causes domain-join to fail.

ℹ️

Note

For more information, see Microsoft article cc758316.

The symptoms of a user-right problem can include the following:

• An attempt to join the domain is unsuccessful.
• The AD Bridge authentication service, lsass, does not start.
• The /opt/pbis/bin/get-status command shows the domain or the AD provider as offline.

You can pin down the issue by using the ldp.exe tool to check whether you can access AD by using the machine account and machine password. Ldp.exe is typically included in the support tools (suptools.msi) for Windows and located on the Windows installation CD (Support folder, Tools subfolder). You might also be able to download the support tools that contain ldp.exe from the Microsoft website.

ℹ️

Note

For more information, see Ldp Overview.

To resolve a user-right issue, you can use Group Policy Modeling in the Group Policy Management Console (GPMC) to find the offending policy setting and then modify it with the Group Policy Management Editor (or the Group Policy Object Editor).

ℹ️

Note

For more information, see Group Policy Modeling.

1. On the AD Bridge client, run the /opt/pbis/bin/lsa ad-get-machine password command as root to get the machine password stored in Active Directory:

/opt/pbis/bin/lsa ad-get-machine password
Machine Password Info:
  DNS Domain Name: EXAMPLE.COM
  NetBIOS Domain Name: EXAMPLE
  Domain SID: S-1-5-21-3190566242-1409930201-3490955248
  SAM Account Name: RHEL5D$
  FQDN: rhel5d.example.com
  Join Type: 1
  Key Version: 0
  Last Change Time: 129401233790000000
  Password: i(2H2e41F7tHN275

2. On a Windows administrative workstation that can connect to AD, start ldp.exe and connect to the domain.

ℹ️

Note

For more information, see LDP UI.

3. In LDP, on the Connection menu, click Bind, and then use the AD Bridge client's SAM account name and machine password from the output of the lsa ad-get-machine password command to bind to the directory.

   

4. If the attempt to bind with the machine account and the machine password fails because of invalid credentials, as in the LDP output image shown, go to the GPMC and use Group Policy Modeling to try to identify the policy setting causing the problem.

5. In the GPMC, run Group Policy Modeling to pinpoint the offending policy setting and then modify the policy setting to grant the correct level of user right to the computer or user.

ℹ️

Note

For more information, see Group Policy Modeling.

In the screen shot, for example, the cause of the problem is that the Deny access to this computer from the network policy setting in the Default Domain Policy GPO contains the domain computers group.

Fix selective authentication in a trusted domain

When you turn on selective authentication for a trusted domain, AD Bridge can fail to look up users in the trusted domain because the machine account is not allowed to authenticate with the domain controllers in the trusted domain. Here is how to grant the machine account access to the trusted domain:

1. In the domain the computer is joined to, create a global group and add the computer's machine account to the group.
2. In the trusted domain, in Active Directory Users and Computers, select the Domain Controllers container and open Properties.
3. On the Security tab, click Advanced, click Add, enter the global group, and then click OK.
4. In the Permission Entry box, under Apply onto, check Computer objects. Under Permissions, find Allowed to Authenticate and check it. Click OK and then click Apply in the Advanced Security Settings box.
5. If you have already joined the AD Bridge client computer to the domain, restart the AD Bridge authentication service:

/opt/pbis/bin/lwsm restart lsass

ℹ️

Note

For more information, see Configuring Selective Authentication Settings.