Assign Fixed UID and GID for AD Users on Linux

By default, SSSD maps UIDs and GIDs dynamically. For fixed mappings, you must first add UNIX attributes (uidNumber, gidNumber) to AD user accounts. This can be done manually or automated using AD tools.

Manual Assignment Using AD Tools

Use Active Directory Users and Computers (ADUC) on a Windows machine:

1. Ensure the “Identity Management for UNIX” feature is installed on your AD domain controller to enable the UNIX Attributes tab.
2. Open ADUC, right-click a user, select Properties, and go to the UNIX Attributes tab.
3. Assign a unique uidNumber (UID) and gidNumber (GID) for the user or group.

Automated Assignment for Bulk Updates

For automating UID/GID assignment across many accounts, use PowerShell on a Windows machine with the ActiveDirectory module. Here’s an example script to bulk-update users in a specific OU (Organizational Unit):

# Import the Active Directory module
Import-Module ActiveDirectory

# Define starting UID and GID values (adjust as needed)
$startUID = 10000
$startGID = 10000  # Or use a fixed GID for all

# Get users from a specific OU (replace with your OU path)
$users = Get-ADUser -Filter * -SearchBase "OU=Users,DC=example,DC=com"

# Loop through users and assign attributes
$uidCounter = $startUID
foreach ($user in $users) {
    # Skip if already set (optional check)
    if (-not (Get-ADUser $user -Properties uidNumber)) {
        Set-ADUser $user -Replace @{
            uidNumber = $uidCounter
            gidNumber = $startGID
            # Add other attributes if needed, e.g., loginShell = "/bin/bash"
        }
        $uidCounter++
    }
}

Write-Host "UID/GID assignment completed."

• Security Note: Ensure UIDs are unique to avoid conflicts. Use a reserved range (e.g., above 10000) to prevent overlap with local system accounts.
• Best Practices: Integrate this into a CI/CD pipeline (e.g., via GitLab CI) for version-controlled automation. Test in a non-production environment first, and monitor with tools like Prometheus for any AD sync issues.

Scheduling or Triggering the Script

To run the script at regular intervals or trigger it when new accounts are created, consider these options based on best practices for automation and security:

• Scheduled Tasks: Use Windows Task Scheduler to run the script periodically (e.g., daily). Create a new task, set it to run as a domain admin account, and configure triggers for time-based execution. This is simple but may miss real-time changes.

• Event-Driven Triggers: For on-demand execution when a new account is created, integrate with Active Directory event logs. Use PowerShell to monitor AD events (e.g., via Event Viewer or tools like NXLog) and trigger the script on user creation events (Event ID 4720). Alternatively, leverage Azure AD Connect or Microsoft Identity Manager for more advanced synchronization and automation.

• CI/CD Integration: If using GitLab CI or similar, wrap the script in a pipeline job triggered by webhooks from AD (if supported) or scheduled stages. This ensures version control and logging.

Always test triggers in a staging environment to avoid AD disruptions, and implement error handling in the script for robustness.

After assigning attributes in AD, configure SSSD on the Linux host by editing /etc/sssd/sssd.conf:

ldap_id_mapping = False
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber

Clear the SSSD cache and restart the service:

sudo rm -f /var/lib/sss/db/*
sudo systemctl restart sssd

Verify the fixed mappings for a user (replace serverworld with an AD username):

id serverworld

This should now display the fixed UID and GID from AD instead of dynamic values.