Fast landing practice of OpenLdap

Keywords: Linux yum Attribute Database Docker

Simply say the value of OPENLDAP to operation and maintenance management, and support the development of enterprise technology, such as GIT, ZABBIX, jmpserver, OA and other large and small systems, as well as the authentication and login of Windows and Linux systems.

If each platform needs to maintain a user management system, then if an employee has N platform permission resignation and regular permission change, it is undoubtedly a challenge for the management, and it is unable to achieve refined permission management.

Through LDAP technology, we can realize centralized management of multi platform account, flexible control of authority, restriction of password strength and its validity period, decouple user management from each platform, and finally realize one-time modification of N places to take effect.

OpenLDAP quick install

The experimental environment is based on CentOS7.4+OpenLDAP2.4.4

Installation package description

Package name Effect
openldap Library files for OpenLDAP server and client
openldap-servers Server program
openldap-clients Client program
openldap-devel Development package, optional
openldap-servers-sql Support sql module, optional
migrationtools Add OpenLDAP users and user groups, import system accounts, optional
compat-openldap OpenLDAP compatibility Library

Reference link:

Related links:< https://ldapwiki.com/wiki/0.9.2342.19200300.100.4.13&gt;

Configure repo source

mkdir /etc/yum.repos.d/backup
mv /etc/yum.repos.d/* /etc/yum.repos.d/backup/
wget -O /etc/yum.repos.d/aliyun-centos7-base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
wget -O /etc/yum.repos.d/aliyun-centos7-epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum clean all
yum makecache

OpenLDAP knowledge foreshadowing

Here are some simple concepts:

  • ldif file: in openLDAP version 2.4, the choice of ldif mode to modify the configuration is added. This mode is effective for dynamically modifying the database without restarting the service. Therefore, it is recommended to use this mode to modify the configuration in subsequent openLDAP versions
  • schema: defines the objectClass available in openldap, and objectClass defines the collection of attributes. If you need to use an attribute, you must first reference the objectClass containing the attribute
  • objectClass: collection of properties.

To summarize: the schema file defines objectClass, and objectClass defines attributes. Attribute is mainly for people to understand and define more easily

If you want to understand this, please refer to:< https://ldapwiki.com/wiki/InetOrgPerson&gt;

For example: add a user Li Li. We use the uid, cn, sn, givenName, mail, userPassword attributes to store Li Li's related information.

dn: uid=lili,ou=develop,ou=Users,dc=tars,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: lili
cn: Li Li
sn: Plum
givenName: Li
mail: lili@tars.com
userPassword: Az123456

## The notes are as follows:
uid: inetOrgPerson Class contains, but with this class, you must inherit
cn: person Class must contain, use this class must inherit top class
sn: person Class must contain, use this class must inherit top class
giveName: inetOrgPerson Class contains, but with this class, you must inherit
mail: inetOrgPerson Class contains, but with this class, you must inherit organizationalPerson
userPassword: person Class must contain, use this class must inherit top class

## Look at the schema of the person class:
objectclass ( 2.5.6.6 NAME 'person'
        DESC 'RFC2256: a person'
        SUP top STRUCTURAL
        MUST ( sn $ cn )
        MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
//The notes are as follows:
2.5.6.6 ## OID, which is mainly used to indicate that it is referenced by ldap internal database.
NAME 'person' ##objectClass class name
SUP top STRUCTURAL ##Dependent upper class
MUST ( sn $ cn ) ##Properties that must be defined to use this objectClass
MAY  ##List of properties contained in the objectClass

Common attribute indications:

Property name describe Give an example
uid User's login name uid=ops,ou=caller,ou=Users,dc=tars,dc=com
cn Usually a person's full name
sn Usually a person's last name
giveName Usually a person's name
dn Unique identifier, the absolute path of an object. uid=ops,ou=dev,ou=Users,dc=tars,dc=com
ou Container for objects, which can be understood as the concept of group For example, the above uid=ops user, under the dev group
dc Usually a domain name For example, DC = tar, DC = com

yum based installation

# install
yum -y install openldap openldap-servers openldap-clients compat-openldap openldap-devel migrationtools

# Generate the encryption key, where the password is the encryption string of root, where - s is the meaning of producing a new password (production forbids low-level string)
[root@mgt-ldap-master1 ~]# slappasswd -s root
{SSHA}k63c6hDYR0kP2KVD7q6iL+t/GrkfF0Az

Generate configuration based on ldap configuration template

The version before 2.4 can be configured quickly based on slapd.conf.obsolete. In the new version, the template configuration file does not exist, but there is a template configuration of ldif, which may be to promote the use of ldif files. Here, we use ldif to initialize the configuration quickly. After openldap is formed, we can maintain a template ldif file to realize rapid production and installation. See the supplement at the bottom of the article for the reference template.

Here is an official link:< https://www.openldap.org/doc/admin24/slapdconf2.html&gt;

The daemons of openldap are slapd, the running user is ldap, and the default port is 389

# cd /etc/openldap
# mv slapd.d slapd.d.bak
# mkdir slapd.d
# cp /usr/share/openldap-servers/slapd.ldif /etc/openldap/
# cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
# vim /etc/openldap/slapd.ldif  ##For the modified initialization ldif file, see the following "schematic description of initialization ldif file" for the configuration file
# slapadd -n 0 -F slapd.d -l slapd.ldif   ##Generate configuration database information
# slapadd -n 0 -F slapd.d -l slapd.ldif
_#################### 100.00% eta   none elapsed            none fast!         
Closing DB...

# chown -R ldap:ldap slapd.d
# chown -R ldap:ldap /var/lib/ldap
# systemctl start slapd
# systemctl enable slapd
# systemctl status slapd

## Instructions for initializing ldif file
# Open comments such as the following line
dn: cn=module,cn=config     ## Turn on the configuration
objectClass: olcModuleList  ## Introduce olcModuleList class
cn: module                  ## Declare module location

olcModulepath:  /usr/lib64/openldap   ## Introduce
olcModuleload: memberof.la     ## When openldap accesses the third-party platform, use this module function
olcModuleload: ppolicy.la      ## Password policy used to set users
olcModuleload: syncprov.la     ## openldap's Master-Slave and master master replication models

## Open all of the following configurations to introduce methods for ease of use. 
include: file:///etc/openldap/schema/core.ldif
include: file:///etc/openldap/schema/collective.ldif
include: file:///etc/openldap/schema/corba.ldif
include: file:///etc/openldap/schema/cosine.ldif
include: file:///etc/openldap/schema/duaconf.ldif
include: file:///etc/openldap/schema/dyngroup.ldif
include: file:///etc/openldap/schema/inetorgperson.ldif
include: file:///etc/openldap/schema/java.ldif
include: file:///etc/openldap/schema/misc.ldif
include: file:///etc/openldap/schema/nis.ldif
include: file:///etc/openldap/schema/openldap.ldif
include: file:///etc/openldap/schema/pmi.ldif
include: file:///etc/openldap/schema/ppolicy.ldif

dn: olcDatabase=hdb,cn=config Next:
olcSuffix: dc=tars,dc=com    ## Set root domain name, everything is based on root
olcRootDN: cn=tarsadmin,dc=tars,dc=com  ## Configure administrator user, remember administrator authentication please write full path
olcRootPW: {SSHA}/xmXwhZMnnXtpErLGiIi2EEoCPNwBQxd  ## To facilitate password configuration during direct initialization, this line adds a new password, which is the ciphertext password generated by slappasswd

Create basic domain

When the basic domain configuration is complete, you can try the above steps again

# ldapadd -x -D cn=superman,dc=tars,dc=com -W -f config_init.ldif
dn: dc=tars,dc=com
dc: tars
objectClass: top
objectClass: domain

Client test

As for the choice of clients, openldap is supported in many ways. I choose ldapaddmin, which is compact and simple, and supports Linux. However, most of the real production operations are done by the web-based ldap client, which uses more phpadmin and LDAP Account Manager

Here we use ldapadmin to complete the basic test operation.

The configuration of ldapadmin is as follows. It should be emphasized that for ldap, the user name is not superman but the absolute complete path of the tree cn=superman,dc=tars,dc=com

Configure slapd logs

# About log level man slapd config search olcLogLevel
# configure log files
mkdir /var/log/slapd
touch /var/log/slapd/slapd.log
chown -R ldap.ldap /var/log/slapd
# Configure rsyslog reception in slapd
vim /etc/rsyslog.d/slapd.conf
local4.*                                                /var/log/slapd/slapd.log
systemctl enable rsyslog;systemctl restart rsyslog

# Add logging policy
vim add_log.ldif 
# ldapadd -Y EXTERNAL -H ldapi:/// -f add_log.ldif
dn: cn=config
changetype: modify
add: olcLogLevel
olcLogLevel: stats

## In fact, the added superscale can also be completed in the initialization file. Add in the initialized slapd.ldif
//Add under dn: cn=config
olcLogLevel: stats

# The log policy is effective. The administrator's permission is used to report the error that the permission is insufficient. The api is used to configure the log ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f add_log.ldif

# Restart the slapd service
systemctl restart slapd

# Check if there is a new log generation
tail -f /var/log/slapd/slapd.log

# Optional log periodic cutting
cat > /etc/logrotate.d/slapd <<EOF
/var/log/slapd/slapd.log{
daily     #Poll once a day
rotate 5  #Save 5 history log files, delete more than
copytruncate #After copying the contents of the source log, empty the file instead of creating a new one
dateext      #When cutting a file, the file name has a date
missingok    #If the specified directory does not exist, an error will be reported. This option is used to suppress the error
}
EOF

# systemctl restart rsyslog

> Test log cutting to see if there is a new file split on the day
# logrotate -f /etc/logrotate.d/slapd

Quickly create Ldap authentication framework

ldap framework

Create primary group Users/Groups/Services

For the writing method of ldif, please refer to:< http://www.openldap.org/software/man.cgi?query=LDIF&sektion=5&apropos=0&manpath=OpenLDAP+2.4-Release#end&gt;

## Write profile
[root@localhost group]# cat groups_init.ldif  ## ldif syntax requires that different groups be separated by spaces
dn: ou=Users,dc=tars,dc=com ##DN of the scheduled modification object
ou: Users   ##What is the object of the operation
objectClass: top    ##Define the class name that the object depends on, and pay attention to the dependency order of the class
objectClass: organizationalUnit

dn: ou=Groups,dc=tars,dc=com
ou: Groups
objectClass: top
objectClass: organizationalUnit

dn: ou=Services,dc=tars,dc=com
ou: Services
objectClass: top
objectClass: organizationalUnit

[root@mgt-ldap-master1 init]# ldapadd -x -D cn=superman,dc=tars,dc=com -W -f 
groups_init.ldif          
Enter LDAP Password: root
adding new entry "ou=Users,dc=tars,dc=com"

adding new entry "ou=Groups,dc=tars,dc=com"

adding new entry "ou=Services,dc=tars,dc=com"

Create Users secondary subdirectory

# cat users_ou_add.ldif
dn: ou=risk,ou=Users,dc=tars,dc=com
ou: risk
objectClass: top
objectClass: organizationalUnit

dn: ou=develop,ou=Users,dc=tars,dc=com
ou: develop
objectClass: top
objectClass: organizationalUnit

dn: ou=bigdata,ou=Users,dc=tars,dc=com
ou: bigdata
objectClass: top
objectClass: organizationalUnit

dn: ou=disable,ou=Users,dc=tars,dc=com
ou: disable
objectClass: top
objectClass: organizationalUnit

[root@mgt-ldap-master1 init]# ldapadd -x -D cn=superman,dc=tars,dc=com -W -f users_ou_add.ldif
Enter LDAP Password: root
adding new entry "ou=risk,ou=Users,dc=tars,dc=com"

adding new entry "ou=develop,ou=Users,dc=tars,dc=com"

adding new entry "ou=bigdata,ou=Users,dc=tars,dc=com"

adding new entry "ou=disable,ou=Users,dc=tars,dc=com"

Create Groups secondary subdirectory

# cat groups_ou_add.ldif
dn: ou=manager,ou=Groups,dc=tars,dc=com
ou: manager
objectClass: top
objectClass: organizationalUnit

Create Services secondary subdirectory

  • Bedding memberof:

    In many scenarios, we need to quickly query which group or groups a user belongs to. memberOf provides such a function: if a user is added through the member attribute in a group, OpenLDAP will automatically create a memberOf attribute on the user, whose value is dn of the group.

  • Why create based on memberof:

    Ordinary ou can only solve the problem of storing object principal. If user A has been created under ou=Users, and if the jumpserver service needs to give user A authentication authority, it only needs to add the DN of user A in the group of jumpserver with the help of the feature of memberof, which ordinary Ou cannot do. The memberof group is not easy to create with client tools. It is recommended to create it with handwriting configuration

# cat services_ou_add.ldif
dn: ou=jumpserver,ou=Services,dc=tars,dc=com
ou: jumpserver
objectClass: top
objectClass: organizationalUnit

dn: ou=gitlab,ou=Services,dc=tars,dc=com
ou: gitlab
objectClass: top
objectClass: organizationalUnit

New users Wang, lily, etc. arrive at the R & D team with the initial password of Az123456

# ldapadd -x -D cn=superman,dc=tars,dc=com -W -f add_user.ldif
dn: uid=lili,ou=develop,ou=Users,dc=tars,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: lili
cn: Li Li
sn: Plum
givenName: Li
mail: lili@tars.com
userPassword: Az123456

dn: uid=xiaowang,ou=develop,ou=Users,dc=tars,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: xiaowang
cn: Xiao Wang
sn: Small
givenName: king
mail: xiaowang@tars.com
userPassword: Az123456

Create the admin and user subgroups of jumpserver

Created based on memberof to facilitate access to third-party platforms.

dn: cn=admin,ou=jumpserver,ou=Services,dc=tars,dc=com
cn: admin
objectClass: top
objectClass: groupOfNames
member: uid=xiaowang,ou=develop,ou=Users,dc=tars,dc=com

dn: cn=user,ou=jumpserver,ou=Services,dc=tars,dc=com
cn: user
objectClass: top
objectClass: groupOfNames
member: uid=xiaowang,ou=develop,ou=Users,dc=tars,dc=com

Create administrator group manager

dn: cn=confadmin,ou=manager,ou=Groups,dc=tars,dc=com
cn: confadmin
objectClass: top
objectClass: groupOfNames
member: uid=xiaowang,ou=develop,ou=Users,dc=tars,dc=com

dn: cn=useradmin,ou=manager,ou=Groups,dc=tars,dc=com
cn: user
objectClass: top
objectClass: groupOfNames
member: uid=lili,ou=develop,ou=Users,dc=tars,dc=com

dn: cn=search_proxy,ou=manager,ou=Groups,dc=tars,dc=com
cn: search_proxy
objectClass: top
objectClass: groupOfNames
member: uid=lili,ou=develop,ou=Users,dc=tars,dc=com

Final effect:

Administrator rights configuration

Front end permission configuration: {- 1}frontend,cn=config

Here, the front-end permission configuration is mainly responsible for the configuration and modification of some objects

[root@mgt-ldap-master1 init]# cat sys_front.ldif 
# ldapadd -Y EXTERNAL -H ldapi:/// -f sys_front.ldif
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: to attrs=userPassword,shadowLastChange by group.exact="cn=useradmin,ou=manager,ou=Groups,dc=tars,dc=com" write by anonymous auth by self write by * none
-
add: olcAccess
olcAccess: to dn.subtree="dc=tars,dc=com" by group.exact="cn=search_proxy,ou=manager,ou=Groups,dc=tars,dc=com" read by group.exact="cn=useradmin,ou=manager,ou=Groups,dc=tars,dc=com" write by users read
-
add: olcAccess
olcAccess: to dn.subtree="" by * read

[root@mgt-ldap-master1 init]# ldapadd -Y EXTERNAL -H ldapi:/// -f front.ldif    
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={-1}frontend,cn=config"

Profile permission configuration: {0}config,cn=config

Here, the configuration file permission configuration makes some openldap global server configuration changes

[root@mgt-ldap-master1 init]# cat sys_config.ldif 
# ldapadd -Y EXTERNAL -H ldapi:/// -f sys_config.ldif
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcAccess
olcAccess: to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by group.exact="cn=confadmin,ou=manager,ou=Groups,dc=tars,dc=com" write by * none

[root@mgt-ldap-master1 init]# ldapadd -Y EXTERNAL -H ldapi:/// -f sys_config.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={0}config,cn=config"

Turn off anonymous access

[root@mgt-ldap-master1 init]# cat authority.ldif 
dn: cn=config
changetype: modify
add: olcDisallows
olcDisallows: bind_anon

Effect comparison between confiadmin and useradmin

[root@mgt-ldap-master1 init]# ldapadd -x -D uid=lili,ou=develop,ou=Users,dc=tars,dc=com -W -f authority.ldif                           
Enter LDAP Password: 
modifying entry "cn=config"
ldap_modify: Insufficient access (50)

[root@mgt-ldap-master1 init]# 
[root@mgt-ldap-master1 init]# ldapadd -x -D uid=xiaowang,ou=develop,ou=Users,dc=tars,dc=com -W -f authority.ldif    
Enter LDAP Password: 
modifying entry "cn=config"

Test after turning off anonymity

Set the password that users can change themselves. It needs to be compared with the above configuration

dn: olcDatabase=frontend,cn=config

olcAccess: to attrs=userPassword,shadowLastChange
by dn.children="ou=Admin,dc=xiodi,dc=cn" write
by anonymous auth
by self write
by * none

Building LAM

# It is recommended to host the external configuration file directly to kubernetes. You can configure it first and then copy the configuration file in docker to form the external configuration
docker run -p 8080:80 -it -d ldapaccountmanager/lam:stable

Step: lam configuration > Edit server profiles > password lam

Set up Self Service Password

Self Service Password this service enables the user to modify / retrieve the password by himself, and solves the problem of password modification. Based on docker construction, the construction of each team is not the same, so only ideas are provided here

You may need to read about the official password modification instructions:

<https://ltb-project.org/documentation/self-service-password&gt;

docker run -p 8081:80 --add-host=smtp.mxhichina.com:10.3.1.25 --name ssp-system -v /data1/self-service-password/conf:/var/www/html/conf -d regist-docker.mgt.tarscorp.com/3rd_ops/self-service-password:latest

Example of accessing jumpserver:

The matching path here is not consistent with the planning, which is only for reference. But ou=jumpserver must be based on the memberof feature

Access to redmine:

Access Windows authentication:

pGina needs to be installed here

Conclusion: due to the new version 2.4 series, there are too few documents available for reference in the whole network at present, and they are not very accurate. This document only provides a quick installation reference, the rest of the general configuration has been reflected in the article. But the password policy ppolicy.la and the highly available syncprov.la module will continue to release our practice and experience sharing if there is time.

Supplementary contents:

Initialize the content supplement of slapd.ldif file

#
# See slapd-config(5) for details on configuration options.
# This file should NOT be world readable.
#

dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/openldap/slapd.args
olcPidFile: /var/run/openldap/slapd.pid
olcLogLevel: stats
#
# TLS settings
#
olcTLSCACertificatePath: /etc/openldap/certs
olcTLSCertificateFile: "OpenLDAP Server"
olcTLSCertificateKeyFile: /etc/openldap/certs/password
#
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#
#olcReferral: ldap://root.openldap.org
#
# Sample security restrictions
#   Require integrity protection (prevent hijacking)
#   Require 112-bit (3DES or better) encryption for updates
#   Require 64-bit encryption for simple bind
#
#olcSecurity: ssf=1 update_ssf=112 simple_bind=64

#
# Load dynamic backend modules:
# - modulepath is architecture dependent value (32/64-bit system)
# - back_sql.la backend requires openldap-servers-sql package
# - dyngroup.la and dynlist.la cannot be used at the same time
#

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
#olcModulepath: /usr/lib/openldap
olcModulepath:  /usr/lib64/openldap
#olcModuleload: accesslog.la
#olcModuleload: auditlog.la
#olcModuleload: back_dn***v.la
#olcModuleload: back_ldap.la
#olcModuleload: back_mdb.la
#olcModuleload: back_meta.la
#olcModuleload: back_null.la
#olcModuleload: back_passwd.la
#olcModuleload: back_relay.la
#olcModuleload: back_shell.la
#olcModuleload: back_sock.la
#olcModuleload: collect.la
#olcModuleload: constraint.la
#olcModuleload: dds.la
#olcModuleload: deref.la
#olcModuleload: dyngroup.la
#olcModuleload: dynlist.la
olcModuleload: memberof.la
#olcModuleload: pcache.la
olcModuleload: ppolicy.la
#olcModuleload: refint.la
#olcModuleload: retcode.la
#olcModuleload: rwm.la
#olcModuleload: seqmod.la
#olcModuleload: smbk5pwd.la
#olcModuleload: sssvlv.la
olcModuleload: syncprov.la
#olcModuleload: translucent.la
#olcModuleload: unique.la
#olcModuleload: valsort.la

#
# Schema settings
#

dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema

include: file:///etc/openldap/schema/core.ldif
include: file:///etc/openldap/schema/collective.ldif
include: file:///etc/openldap/schema/corba.ldif
include: file:///etc/openldap/schema/cosine.ldif
include: file:///etc/openldap/schema/duaconf.ldif
include: file:///etc/openldap/schema/dyngroup.ldif
include: file:///etc/openldap/schema/inetorgperson.ldif
include: file:///etc/openldap/schema/java.ldif
include: file:///etc/openldap/schema/misc.ldif
include: file:///etc/openldap/schema/nis.ldif
include: file:///etc/openldap/schema/openldap.ldif
include: file:///etc/openldap/schema/pmi.ldif
include: file:///etc/openldap/schema/ppolicy.ldif
#
# Frontend settings
#

dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
#
# Sample global access control policy:
#   Root DSE: allow anyone to read it
#   Subschema (sub)entry DSE: allow anyone to read it
#   Other DSEs:
#       Allow self write access
#       Allow authenticated users read access
#       Allow anonymous users to authenticate
#
#olcAccess: to dn.base="" by * read
#olcAccess: to dn.base="cn=Subschema" by * read
#olcAccess: to *
#   by self write
#   by users read
#   by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#

#
# Configuration database
#

dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcAccess: to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,c
 n=auth" manage by * none

#
# Server status monitoring
#

dn: olcDatabase=monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: monitor
olcAccess: to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,c
 n=auth" read by dn.base="cn=tarsadmin,dc=tars,dc=com" read by * none

#
# Backend database definitions
#

dn: olcDatabase=hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: hdb
olcSuffix: dc=tars,dc=com
olcRootDN: cn=tarsadmin,dc=tars,dc=com
olcRootPW: {SSHA}k63c6hDYR0kP2KVD7q6iL+t/GrkfF0Az
olcDbDirectory: /var/lib/ldap
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub

Supplement of LDIF writing skills under LDAP

Reference:< http://www.openldap.org/software/man.cgi?query=LDIF&sektion=5&apropos=0&manpath=OpenLDAP+2.4-Release#end&gt;

Add object:

[root@localhost scripts]# cat config_init.ldif 
# ldapadd -x -D cn=tarsadmin,dc=tars,dc=com -W -f config_init.ldif
dn: dc=tars,dc=com
dc: tars
objectClass: top
objectClass: domain

Change object value:

# modify can add, delete, and replace
# -Indicates inheriting the previous dn
# Space for next entry

dn: cn=Babs Jensen,dc=example,dc=com
changetype: modify
add: givenName
givenName: Barbara
givenName: babs
-
replace: description
description: the fabulous babs
-
delete: sn
sn: jensen
-

dn: cn=Babs Jensen,dc=example,dc=com
changetype: modrdn
newrdn: cn=Barbara J Jensen
deleteoldrdn: 0
newsuperior: ou=People,dc=example,dc=com

LDAP supplement on ACL

Introduction to access control ACL

Access control is mainly defined in three aspects:

The < what > section selects the entry and / or attribute accessed by the application,
The < who > section specifies which entity access is granted,
The < access > section specifies the access granted.

#In general, which entries set which permissions for who

Specific implementation format

access to [what]      
       by [who] [access]
       by [who] [access]
What (control access to what)

The < what > section of the access specification identifies the entries and attributes that apply access control. There are three ways to choose items:

• through DN
 • through filters.
• by attributes
Determined by DN
to * // Select all
to dn[.<basic-style>]=<regex> // Use regular
to dn.<scope-style>=<DN> // Scope of use

//Expression instance:
access to dn.regex="uid=,+,ou=Users,dc=example,dc=com"
//Range:
base,one,subtree,children
Determined by filter
to filter=<ldap filter>

//Example:
access to filter=(objectClass=person)
# Match entries with person object classes

access to filter="(|(|(givenName=Matt)(givenName=Barbara))(sn=Kant))"
# Matching satisfies (sn=Kant) or (| (givenName=Matt)(givenName=Barbara)),, while (| (givenName=Matt)(givenName=Barbara)) means satisfying (givenName=Matt) or (givenName=Barbara)

access to dn.subtree="ou=Users,dc=example,dc=com" filter="(employeeNumber=*)"
# Matching meets ou=Users,dc=example,dc=com and down...
Determined by attr
attrs=<attribute list>
attrs=<attribute> val[.<style>]=<regex>

//Example:
to attrs=userPassword,shadowLastChange
#Match contains properties userPassword,shadowLastChange
who (to whom access is granted)

The < who > section identifies the entity to which access is granted. Note that access is granted to entities rather than items.

The following table summarizes the entity specifiers:

Explain entity
* All, including anonymous and authenticated
anonymous Anonymous user (not authenticated)
users Authenticated users
self Users associated with the target entry
dn[.<basic-style>]=<regex> Users matching regular expressions
dn.<scope-style>=<DN> Users in DN range
access (permission definition)
Granular authority
The < access > type granted can be one of the following:

w: Write access to a record or property.
r: Read access to a record or property.
s: Search access to a record or property.
c: Access to run a comparison operation on a record or property.
x: Access to perform server-side authentication operations on records or properties.
d: Access to information about the existence of records or attributes (D for "disclosure").
0: access to records or properties is not allowed. This is equivalent to - wrscxd.
m: Manage permissions
Common permissions

Posted by brewfan9 on Tue, 28 Apr 2020 03:28:48 -0700