Difference between revisions of "Idmap config ad"

(Indicated that users not having a 'server services' line, don't need any changes to activate Winbindd)
m (Rewrite to only show relevant info: removed reference to idmap lines etc, they do not do anything on a samba 4.2.0 DC)
Line 3: Line 3:
 
[https://www.rfc-editor.org/rfc/rfc2307.txt RFC2307] defines the possibility to store e. g. user and group information in an LDAP directory. This allows central administration with several [[#Advantages|advantages]].
 
[https://www.rfc-editor.org/rfc/rfc2307.txt RFC2307] defines the possibility to store e. g. user and group information in an LDAP directory. This allows central administration with several [[#Advantages|advantages]].
  
RFC2307 attributes are per default in place in a Samba Active Directory. This documentation describes how to make account and group information available on [[Setup_a_Samba_AD_Member_Server|Member Servers]] via [[Winbind|Winbindd]] using RFC2307.
+
RFC2307 attributes are usable by default in a Samba Active Directory. This documentation describes how to make account and group information available on [[Setup_a_Samba_AD_Member_Server|Member Servers]] via [[Winbind|Winbindd]] using RFC2307.
  
Since Samba 4.2, Winbindd is able to be used on a Samba Domain Controller, as well. Previous version were shipped with Winbind - a new implementation, that was dropped meanwhile because it hasn't the same quality and feature set of Winbindd, that was used in Samba Member Server code. The Samba team advices only to use Winbindd on 4.2 or later. If you're running 4.0 or 4.1, choose one of the alternatives [[Local_user_management_and_authentication/sssd|sssd]] or [[Local_user_management_and_authentication/nslcd|nslcd]].
+
Since Samba 4.2.0, Winbindd (as used on a member server) is now used by default on a Samba Domain Controller. Previous version were shipped with Winbind - an implementation that was dropped because it doesn't have the same quality and feature set of Winbindd. The Samba team advice is to only use Winbindd on 4.2.0 or later. If you're running 4.0 or 4.1, choose one of the alternatives [[Local_user_management_and_authentication/sssd|sssd]] or [[Local_user_management_and_authentication/nslcd|nslcd]].
  
  
Line 31: Line 31:
 
= General information about the Samba idmap_ad backend for Winbindd =
 
= General information about the Samba idmap_ad backend for Winbindd =
  
The idmap_ad plugin provides a way for Winbindd to read id mappings from an AD server that uses RFC2307/SFU schema extensions. This module implements only the "idmap" API, and is read-only. Mappings must be provided in advance by the administrator by adding the uidNumber attributes for users and gidNumber attributes for groups in the AD. Winbindd will only map users that have a uidNumber and whose primary group have a gidNumber attribute set. It is however recommended that all groups in use have gidNumber attributes assigned, otherwise they are not working.
+
The idmap_ad plugin will ultimately provide a way for Winbindd to read id mappings from an AD server that uses RFC2307/SFU schema extensions. This module implements only the "idmap" API, and is read-only. Mappings must be provided in advance by the administrator by adding the uidNumber attributes for users and gidNumber attributes for groups in the AD. Winbindd will only map users that have a uidNumber and whose primary group have a gidNumber attribute set. It is however recommended that all groups in use have gidNumber attributes assigned, otherwise they will not work.
 
 
The writeable default config („idmap config *“) is also needed in order to be able to create group mappings. This catch-all default idmap configuration should have a range that is disjoint from any explicitly configured domain with idmap backend ad.
 
  
 
See the manpage of idmap_ad for further information.
 
See the manpage of idmap_ad for further information.
Line 43: Line 41:
 
= Using Winbindd on a Samba DC =
 
= Using Winbindd on a Samba DC =
  
On a DC, UID/GID resolving to user-/groupnames on OS side is optional. If you're fine with seeing UIDs/GIDs on your DC, instead of user-/groupnames, no further action is required. However if you want to have user-/groupnames displayed on 'ls', etc., you can choose doing it via Winbindd (see this section), [[Local_user_management_and_authentication/nslcd|nslcd]] or [[Local_user_management_and_authentication/sssd|sssd]].
+
On a DC, UID/GID resolving to user/groupnames on the OS side is optional. If you're fine with seeing UIDs/GIDs on your DC, instead of user/groupnames, no further action is required. However if you want to have user/groupnames displayed on 'ls', etc., you can choose to do it via Winbindd (see this section), [[Local_user_management_and_authentication/nslcd|nslcd]] or [[Local_user_management_and_authentication/sssd|sssd]].
 
 
Since Samba 4.2, Winbindd is able to be used on a Samba Domain Controller, as well. The following smb.conf change is additionally necessary to enable Winbindd on a Samba DC, compared to a member server:
 
 
 
Users having a „server services“ line in their DC smb.conf, need to replace the „winbind“ entry by „winbindd“:
 
 
 
[global]
 
  ...
 
  server services = ....., <s>winbind,</s> <u>winbindd</u>
 
 
 
Users not having a „server services“ line, don't need any changes. Winbindd is enabled per default for the "server services" parameter.
 
 
 
Winbindd is automatically be started by the „samba“ process on startup and need not to be run manually!
 
 
 
Additionally the steps described in [[#Configuring_RFC2307_backend_for_Winbindd|Configuring RFC2307 for Winbindd]] are required.
 
 
 
 
 
 
 
 
 
 
 
= Configuring RFC2307 backend for Winbindd =
 
 
 
Add the following to the [global] section of your smb.conf:
 
  
  # '''Important: The ranges of the default (*) backend'''
+
Since Samba 4.2.0, Winbindd is now used on a Samba Domain Controller, instead of the winbind built into the "samba" process.
  # '''and the domain(s) <u>must not</u> overlap!'''
 
 
  # Retrieve UIDs/GIDs for domain SAMDOM from AD, via RFC2307.
 
  # The range value defines the lowest RID up to the highest,
 
  # that will ever be used in this domain. Ask your AD Domain
 
  # Administrator, if you don't know which range to define.
 
  idmap config SAMDOM:backend = ad
 
  idmap config SAMDOM:schema_mode = rfc2307
 
  idmap config SAMDOM:range = 10000-40000
 
 
  # Store UIDs/GIDs for all other domains (including local
 
  # accounts/groups of this server) in a tdb file
 
  idmap config *:backend = tdb
 
  idmap config *:range = 2000-9999
 
 
  # Use home directory and shell information from AD
 
  winbind nss info = rfc2307
 
  
See the manpage of smb.conf for additional winbindd parameters and their meanings.
+
Winbindd is automatically started by the "samba" process on startup and should not to be run manually!
  
  

Revision as of 10:12, 16 June 2015

Introduction

RFC2307 defines the possibility to store e. g. user and group information in an LDAP directory. This allows central administration with several advantages.

RFC2307 attributes are usable by default in a Samba Active Directory. This documentation describes how to make account and group information available on Member Servers via Winbindd using RFC2307.

Since Samba 4.2.0, Winbindd (as used on a member server) is now used by default on a Samba Domain Controller. Previous version were shipped with Winbind - an implementation that was dropped because it doesn't have the same quality and feature set of Winbindd. The Samba team advice is to only use Winbindd on 4.2.0 or later. If you're running 4.0 or 4.1, choose one of the alternatives sssd or nslcd.



Advantages

  • Central administration of users (UID, Login Shell, Home Directory, Primary Group) and groups (GID) directly in Active Directory.
  • Consistent user and group information accross multiple machines.
  • Individual settings for users (e. g. for Login Shell). Other mapping technologies typically use global template settings for all accounts on a host.
  • Central management prevents the necessity for local ID mappings, that may cause loosing file ownership if the local database corrupts.
  • Easy user/group management via the default Microsoft tools (e. g. Active Directory Users and Computers), which are part of RSAT.
  • If administered via ADUC and enabled NIS extensions, there's no need for manual ID counting. E. g. the next free UID and GID is stored directly in Active Directory and will be incremented then creating a new user or group.



General information about the Samba idmap_ad backend for Winbindd

The idmap_ad plugin will ultimately provide a way for Winbindd to read id mappings from an AD server that uses RFC2307/SFU schema extensions. This module implements only the "idmap" API, and is read-only. Mappings must be provided in advance by the administrator by adding the uidNumber attributes for users and gidNumber attributes for groups in the AD. Winbindd will only map users that have a uidNumber and whose primary group have a gidNumber attribute set. It is however recommended that all groups in use have gidNumber attributes assigned, otherwise they will not work.

See the manpage of idmap_ad for further information.



Using Winbindd on a Samba DC

On a DC, UID/GID resolving to user/groupnames on the OS side is optional. If you're fine with seeing UIDs/GIDs on your DC, instead of user/groupnames, no further action is required. However if you want to have user/groupnames displayed on 'ls', etc., you can choose to do it via Winbindd (see this section), nslcd or sssd.

Since Samba 4.2.0, Winbindd is now used on a Samba Domain Controller, instead of the winbind built into the "samba" process.

Winbindd is automatically started by the "samba" process on startup and should not to be run manually!



Administering Unix Attributes in Active Directory

See Administer_Unix_Attributes_in_Active_Directory.