Difference between revisions of "Samba AD schema extensions"

From SambaWiki
Line 134: Line 134:
==Adding your schema==
==Adding your schema==
* Ensure you do this first on a [[Create_a_samba_lab-domain lab-domain backup of your production domain]]
* Create two LDIF files, attrs.ldif (with the attributes) and classes.ldif (the object classes) and copy to the schema master server (if you were working on a different server)
* Create two LDIF files, attrs.ldif (with the attributes) and classes.ldif (the object classes) and copy to the schema master server (if you were working on a different server)
* Apply the ldifs with commands similar to:
* Apply the ldifs with commands similar to:

Revision as of 10:25, 26 May 2020

Schema Extension in Samba Active Directory

Samba AD supports the same kind of schema extensions as Microsoft Active Directory. Schema updates in AD are a sensitive action and you must be prepared to do a full restore of the DC holding the role of schema master if something goes wrong.

This is even more true in Samba 4 given it does not always generate some critical attributes that are generated on Microsoft AD and this lack of attributes can lead to a un-start-able samba provision. This is why schema updates in Samba AD are currently disabled by default.

In order to allow them, the option dsdb:schema update allowed must be set to true in the smb.conf or passed on the command line.

Verified Schema Extensions

As getting an LDIF that won't ruin the provision can be hard, this page will list LDIFs that are known not to break the database.

Perform these updates only if you need them and if you know how to restore the provision on the schema master.

NIS Extensions

See Installing the NIS Extensions.


This extension allow you to store automount information in LDAP. In order to add this extension, follow these steps:

  • Download Automount_template.ldif.txt, this is a template that will be transformed in the next steps
  • Locate the rootDN of your provision: ldbsearch -H ldap://ip_of_server -U administrator -s base dn
  • Run cat automount_template.ldif | sed 's/DOMAIN_TOP_DN/value_of_rootDN_obtained_in_previous_step/' > automount.ldif
  • Split the resulting file into two, one containing the attributes, the other containing the objectclasses
  • Name the two new files automount_attrs.ldif and automount_classes.ldif
  • Stop Samba4 on the schema master
  • Copy automount_attrs.ldif and automount_classes.ldif to the schema master server (if you were working on a different server)
  • Apply the ldifs with commands similar to:
    • ldbmodify -H path_to_sam_ldb automount_attrs.ldif --option="dsdb:schema update allowed"=true
    • ldbmodify -H path_to_sam_ldb automount_classes.ldif --option="dsdb:schema update allowed"=true

Building your own schema extensions


Internal use and experimental Samba OIDs is reserved in Samba for use by Samba installations internally.

Wiki OIDs

If you use a OID from this range, please note your use below.

  • Attributes in examples in this wiki page
  • Classes in examples in this wiki page
  • Next available arc.

Syntax for attributes

  • See Microsoft's Documentaion on choosing a syntax
  • You need to choose the Syntax ID attributeSyntax (eg, Samba will map that to the and OM ID (eg 4) for you.
  • Decide if this will be isSingleValued (TRUE or by default FALSE)


  • You need a clear, ideally globally unique, name for your attribute or class, this will be the ldapDisplayName and CN
  • Consider re-using names from [schema.org schema.org] if there is no existing example for LDAP
  • LDAP schema are traditionally camalCase with a lowercase initial letter

Fill in your this template

This will create a new auxiliary class to allow your new attribute to be stored

dn: CN=${NAME},CN=Schema,CN=Configuration,${DOMAIN_TOP_DN}
objectClass: attributeSchema
attributeID: ${OID}
lDAPDisplayName: ${NAME}
description: ${DESCRIPTION}
isSingleValued: TRUE
dn: CN=${CLASS_NAME},CN=Schema,CN=Configuration,${DOMAIN_TOP_DN}
objectClass: classSchema
governsID: ${CLASS_OID}
lDAPDisplayName: ${CLASS_NAME}
subClassOf: top
objectClassCategory: 3
description: ${DESCRIPTION}
mayContain: ${NAME}


The startDate is recorded as a string per this advice and per the ISO 8601 date format that a Date is specified as for schema.org schemas.

dn: CN=startDate,CN=Schema,CN=Configuration,DC=samba,DC=example,DC=com
objectClass: attributeSchema
lDAPDisplayName: startDate
description: Role start date
isSingleValued: TRUE

dn: CN=endDate,CN=Schema,CN=Configuration,DC=samba,DC=example,DC=com
objectClass: attributeSchema
lDAPDisplayName: endDate
description: Role end date
isSingleValued: TRUE

dn: CN=roleName,CN=Schema,CN=Configuration,DC=samba,DC=example,DC=com
objectClass: attributeSchema
lDAPDisplayName: roleName
description: Role name
isSingleValued: TRUE
dn: CN=role,CN=Schema,CN=Configuration,DC=samba,DC=example,DC=com
objectClass: classSchema
lDAPDisplayName: role
subClassOf: top
objectClassCategory: 3
description: A Role
mayContain: startDate
mayContain: endDate
mayContain: roleName

Adding your schema

ldbadd -H path_to_sam_ldb attrs.ldif --option="dsdb:schema update allowed"=true
ldbadd -H path_to_sam_ldb classes.ldif --option="dsdb:schema update allowed"=true

Test your new schema

  • Modify an object to have your new objectclass additionally listed
  • Modify the same object to add the attribute. Samba currently, incorrectly, requires that this be a distinct modification.