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>
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>
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>
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>
## 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>
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>
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