SUSE Support

Here When You Need Us

How To Set Up A Basic idmap_ad Backend On SLES 11 SP 1

This document (7007419) is provided subject to the disclaimer at the end of this document.


SUSE Linux Enterprise Server 11 Service Pack 1


After reviewing TID 7007006, some users have desired additional assistance in setting up a basic idmap_ad backend.  This TID will identify the basic steps to accomplish this.  The Windows Server used is Windows 2003 with SFU installed.



Additional Information

The following are the basic steps I followed in setting up my idmap_ad backend on a SLES 11 server:
  1. The first step is to make sure that time is in sync for the SLES 11 server and the Windows server. I cannot over emphasize the importance of this step.
  2. Edit the /etc/resolv.conf file on the SLES server and include a 'nameserver ip.addr.of.srvr' entry that points the SLES' DNS to the Active Directory (AD) server.
  3. Install Services For UNIX (SFU) on the Windows 2003 server, or the Windows AD Role "Identity Management for UNIX" as found under the Server Manager under other distributions.  Under the UNIX ATTRIBUTES tab of the user object properties (as found under AD), various attributes (such as UID) can be set.  For testing purposes (as outlined under step 7), configure this for at least one user.
  4. Launch 'yast2 samba-client' from a shell, or open YAST > WINDOWS DOMAIN MEMBERSHIP and do the following:
    • After the domain/workgroup is verified, change the "Domain or Workgroup" field to the netbios name of your domain.
    • Check the box "Also Use SMB Information for Linux Authentication"
    • Click OK, and authenticate to the AD server.
  5. Edit the /etc/samba/smb.conf. Under the [global] section, do the following:
    • Make sure the "workgroup =" contains the netbios name of the domain as specified under the WINDOWS DOMAIN MEMBERSHIP plugin as mentioned in the previous step
    • Make sure "realm = " is set to the domain name (this should have been already completed by the plugin--if not, rerun the plugin)
    • Security should be set to ADS (should have been done already)
    • Add the following entries:

      idmap backed = tdb
      idmap uid = 21000-30000
      idmap gid = 21000-30000
      idmap config YourDomain: backend = ad
      idmap config YourDomain: range = 10000-20000
      idmap config YourDomain: schema_mode = sfu
    • Now, a couple of notes about the above configuration:
      1. 'idmap config YourDomain:range' is a filter. This specifies the range of users on the AD server that are to be filtered or included on this systems winbind queries. For instance, if I have two users configured in AD, and one as a UID of 9999 and the other has a UID of 10000, then only the user with the UID of 10000 will be included in our searches because the range specified only includes users 10000-20000. Modify this range to fit your needs.
      2. 'idmap uid/gid =' is probably already in the smb.conf. The important thing to remember is that the range specified in this parameter should not overlap the 'idmap config YourDomain:range' and should not overlap local users. Local users are usually in the 0-1000+ range (depending on the number of users configured). Just in case I decide to create thousands of local users in the future, I changed the 'idmap uid/gid' range to something that wouldn't interfere with those potential assignments
      3. 'idmap config YourDomain:schema_mode' will either be 'sfu' or 'rfc2307' depending on your setup. If SFU is installed on the AD server, then sfu is the schema_mode utilized. If Identity Management for UNIX is utilized, then rfc2307 will be the schema_mode utilized. Having the wrong schema_mode specified will prevent the idmap_ad backend from working properly.
  6. Save the smb.conf file. Backup the /var/lib/samba/*tdb files, delete them from that directory, and restart winbind
    • winbind stores the mappings in these files. As we are changing the way the mappings are being stored, we are deleting them and letting winbind recreate them with the new information as configured with the smb.conf. It is a good idea to back these up regularly in case something were to happen to these files
  7. Test your setup by doing the following:
    • wbinfo -u (DOMAIN\users should be returned, where DOMAIN is your domain name and users are the users configured with UIDs)
    • id user (where user is the user as seen in the output of the previous command. IE. MyDomain\testuser will need to be tested with 'id MyDomain\\testuser' (the \ has to be escaped))
    • Assuming users are returned via 'wbinfo -u' (or groups for that matter), and the same user/group can be id'd and output returned, everything should be working at this point with the idmap_ad backend
    • NOTE: The UID returned should match the UID of the user in AD (the key point of idmap_ad)
    • NOTE:  It may take some time for the user mappings to be pulled across by winbind.  For instance, in my testing, it took a few minutes for userA to show up, and another couple of minutes for userB to show up. 
Some optional, useful settings:
  • winbind nss info = <sfu/rfc2307> (See the man page for smb.conf for more details)
  • winbind use default domain = yes (wbinfo will return UserName instead of Domain\UserName)
  • 'winbind enum users = no' and 'winbind enum groups = no' (this is default, but setting these to yes is not recommended for production environments as it can really slow things down)
Below is a copy of the [global] section of a working smb.conf after following the above steps:


workgroup = TESTDOM
passdb backend = tdbsam
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
include = /etc/samba/dhcp.conf
logon path =\\profiles\.msprofile
logon home =\\%L\%U\.9xprofile
logon drive = P:
usershare allow guests = No
security = ADS
template homedir = /home/%D/%U
template shell = /bin/bash
winbind refresh tickets = yes

# Below was manually entered

winbind use default domain = yes
winbind nss info = sfu
idmap backend = tdb
idmap uid = 21000-30000
idmap gid = 21000-30000
idmap config TESTDOM: backend = ad
idmap config TESTDOM: range = 10000-20000
idmap config TESTDOM: schema_mode = sfu


NOTE:  SLES 11 SP 2 and beyond deprecate the idmap uid/gid options in favor for "idmap config *: range".  In order for winbind to work correctly this will need to be included in the configuration.


winbind use default domain = yes
idmap config TESTDOM: backend = ad
idmap config TESTDOM: range = 10000-20000
idmap config TESTDOM: schema_mode = rfc2307
idmap config *: range = 1000-9999
Troubleshooting:  While winbind doesn't require Identity Management for Unix (IMFU) or Services for Unix (SFU) to be installed to operate, the use of  "backend = ad" does require the services to be installed to map correctly.  Winbind will map to the TDB backend fine without IMFU or SFU.  While utilizing backend = ad, however, should a user coming across winbind not map correctly to the specified backend's range, or map at all, then double-check the user in the Windows environment.  Check the properties of the user, and check the "Members Of" tab.  The primary group specified for the user must be Unix enabled.  If it isn't mapping issues can occur.  Either make the primary group Unix enabled, or change the primary group to a group that is Unix enabled. 



This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7007419
  • Creation Date: 22-Dec-2010
  • Modified Date:16-Mar-2021
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.