Today, we will focus on creating a new auxiliary ObjectClass for Samba Active Directory with its own attributes.
But first, an important note:
Changing the schema is a major intervention in the structure of Active Directory and should be carefully considered and planned. Once a change has been imported into Active Directory, it cannot be undone! Before importing, you should always back up your Active Directory. Always test the schema change in a test environment first!
The procedure for importing a new object class and new attributes is different here than you may be familiar with from OpenLDAP. In the first step, you must always enter the attributes in the schema first; only then can the object class be imported. In this example, two new attributes are to be created, which can then be assigned to individual users later. If you have not already done so, you should definitely register your own ODI with IANA to keep your ObjectClass and attributes unique worldwide. Your own ODI always starts with 1.3.6.1.4.1. You will then receive a six-digit number from IANA. Here, I have used “123456” for demonstration purposes. The numbers after the OID can be freely selected. The first ‘1’ always refers to my first own ObjectClass. Each additional new ObjectClass is always incremented by ‘1’. The following numbers indicate the position of the attribute. All new attributes are always incremented by ‘1’. Always use a suffix for your object class and your attributes to ensure that the name is unique. I use “stka” here. Now follows the LDIF for the attributes.
————-
dn: CN=stka-birthday,CN=Schema,CN=Configuration,DC=example,DC=net
objectClass: top
objectClass: attributeSchema
cn: stka-birthday
attributeID: 1.3.6.1.4.1.123456.1.1
lDAPDisplayName: stka-birthday
attributeSyntax: 2.5.5.12
omSyntax: 64
isSingleValued: TRUE
searchFlags: 0
description: User’s birthday (date as string)dn: CN=stka-kfz,CN=Schema,CN=Configuration,DC=example,DC=net
objectClass: top
objectClass: attributeSchema
cn: stka-kfz
attributeID: 1.3.6.1.4.1.123456.1.2
lDAPDisplayName: stka-kfz
attributeSyntax: 2.5.5.12
omSyntax: 64
isSingleValued: TRUE
searchFlags: 0
description: User’s vehicle identification number (string)
————-
But where do the values for attributeSyntax and omSyntax come from? To find out, download the sources for your Samba version from the website www.samba.org. After unpacking the file, search for the file source4/dsdb/schema/schema_syntax.c. In the file, search for the pattern ‘static const struct’. Below this, you will find the values for the various syntax attributes. There you will also find which format is valid for the attribute.
After you have created the file, you can import the attributes with the following command:
ldbmodify -H /var/lib/samba/private/sam.ldb /root/new-attrib.ldif –option=“dsdb:schema update allowed”=true
This option is mandatory, as changing the schema is normally blocked.
The new ObjectClass can then be created. The following listing shows an example:
————
dn: CN=stka-user,CN=Schema,CN=Configuration,DC=example,DC=net
objectClass: top
objectClass: classSchema
cn: stka-user
governsID: 1.3.6.1.4.1.123456.1.3
lDAPDisplayName: stka-user
subClassOf: top
objectClassCategory: 3
mayContain: stka-birthday
mayContain: stka-car
description: Auxiliary ObjectClass for extending user objects
————
Then you can import the ObjectClass:
ldbmodify -H /var/lib/samba/private/sam.ldb /root/new-objectclass.ldif –option=“dsdb:schema update allowed”=true
For all subsequent changes to the objects, always use the command:
ldbmodify -H /var/lib/samba/private/sam.ldb <file.ldif>
Now create an LDIF to add the new ObjectClass to a user:
———–
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
add: objectClass
objectClass: stka-user
———–
Only now can the new attributes be added to the user. The following LDIF is required for this:
——– —
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
add: stka-birthday
stka-birthday: 1990-05-14
–
add: stka-vehicle
stka-vehicle: AB-XY-1234
———–
The user has now been changed and the change can be displayed:
————
root@dc01:~# ldbsearch -H /var/lib/samba/private/sam.ldb cn=Karl_Klammer
# record 1
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
cn: Karl_Klammer
instanceType: 4
whenCreated: 20251030190730.0Z
uSNCreated: 4080
name: Karl_klammer
objectGUID: 8c932e96-9ae7-4d77-b0f8-62553617cfe8
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
primaryGroupID: 513
objectSid: S-1-5-21-1270304378-1688964665-1878507777-1106
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: Karl_klammer
sAMAccountType: 805306368
userPrincipalName: Karl_klammer@example.net
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=example,DC=net
pwdLastSet: 134063248508330770
userAccountControl: 512
objectClass: top
objectClass: stka-user
objectClass: person
objectClass: organizationalPerson
objectClass: user
stka-birthday: 1990-05-14
stka-vehicle: AB-XY-1234
whenChanged: 20251030191518.0Z
uSNChanged: 4084
distinguishedName: CN=Karl_klammer,CN=Users,DC=example,DC=net# Referral
ref: ldap://example.net/CN=Configuration,DC=example,DC=net# Referral
ref: ldap://example.net/DC=DomainDnsZones,DC=example,DC=net# Referral
ref: ldap://example.net/DC=ForestDnsZones,DC=example,DC=net# returned 4 records
# 1 entries
# 3 referrals
————
Of course, the values in the user objects can also be changed or deleted. To do this, a corresponding LDIF is required again. First, you will see the LDIF for changing one of the two attributes:
————
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
replace: stka-birthday
stka-birthday: 1999-05-14
————
The following listing shows the deletion of an attribute
————
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
delete: stka-birthday
————
To remove the ObjectClass from an object, all attributes of the ObjectClass must first be removed from the object. This requires the LDIF from the following listing:
————
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
delete: objectClass
objectClass: stka-user
——– —-
Please note: The imported attributes and object classes cannot be removed again.
This allows you to extend your Samba AD with your own object classes and attributes in the future.