OpenLDAP command summary
- ldapsearch: Search for OpenLDAP directory tree entries.
- ldapadd: Adds directory tree entries via LDIF format.
- ldapdelete: Deletes OpenLDAP directory tree entries.
- ldapmodify: Modify the OpenLDAP directory tree entry.
- ldapwhoami: Validates the identity of OpenLDAP users.
- ldapmodrdn: Judges the OpenLDAP directory tree DN entry.
- ldapcompare: Determines whether the DN value and the specified parameter value belong to the same entry.
- ldappasswd: Modify the OpenLDAP directory tree user entry to achieve a password reset.
- slaptest: Verify the slapd.conf file or cn=configuration directory.
- slapindex: Creates an OpenLDAP directory tree index to provide query efficiency.
- slapcat: Converts data to LDIF files for OpenLDAP.
ldapadd command
options | description | -x | Perform simple authentication | -D | The DN used to bind the server | -h | The address of the directory service | -w | Bind DN password | -f | Files that use LDIF files for entry addition |
First, we prepare a test.ldif file with the following command:
The content is as follows:
dn: uid=xzz,ou=Users,dc=itsvse,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
homeDirectory: /home/itsvse_xzz
loginShell: /bin/bash
cn: xzz
uidNumber: 1000
gidNumber: 1000
sn: System Administrator
mail: xzz@itsvse.com
postalAddress: shanghai
mobile: 13788888888
Add commands as follows:
After entering the password, it is successfully added, as shown in the figure below:
ldapmodify command
The ldapmodify command is fixed and mainly implements different modification functions through configuration files.
The demo.ldif file is as follows, which means that the uidNumber parameter of the user uid=xzz is modified.
ldappasswd command
ldappasswd opens a connection to the LDAP server and changes the entry password.
options | description | -x | Perform simple authentication | -D | The DN used to bind the server | -w | Bind DN password | -S | Enter the password when prompted | -s | pass to set the password to pass | -a | pass set old passwd to pass | -A | Prompt the setting of old passwd | -H | refers to the server to be bound | -I | Use the SASL session method |
ldapsearch command
ldap search command
[root@VM_0_9_centos ~]# ldapsearch -h
ldapsearch: option requires an argument -- 'h'
ldapsearch: unrecognized option -h
usage: ldapsearch [options] [filter [attributes...]]
where:
filter RFC 4515 compliant LDAP search filter
attributes whitespace-separated list of attribute descriptions
which may include:
1.1 no attributes
* all user attributes
+ all operational attributes
Search options:
-a deref one of never (default), always, search, or find
-A retrieve attribute names only (no values)
-b basedn base dn for search
-c continuous operation mode (do not stop on errors)
-E [!] <ext>[=<extparam>] search extensions (! indicates criticality)
[!] domainScope (domain scope)
!dontUseCopy (Don't Use Copy)
[!] mv=<filter> (RFC 3876 matched values filter)
[!] pr=<size>[/prompt|noprompt] (RFC 2696 paged results/prompt)
[!] sss=[-]<attr[:OID]>[/[-]<attr[:OID]>...]
(RFC 2891 server side sorting)
[!] subentries[=true|false] (RFC 3672 subentries)
[!] sync=ro[/<cookie>] (RFC 4533 LDAP Sync refreshOnly)
rp[/<cookie>][/<slimit>] (refreshAndPersist)
[!] vlv=<before>/<after>(/<offset>/<count>|:<value>)
(ldapv3-vlv-09 virtual list views)
[!] deref=derefAttr:attr[,...] [; derefAttr:attr[,...] [; ...]]
[!] <oid>[=:<b64value>] (generic control; no response handling)
-f file read operations from `file'
-F prefix URL prefix for files (default: file:///tmp/)
-l limit time limit (in seconds, or "none" or "max") for search
-L print responses in LDIFv1 format
-LL print responses in LDIF format without comments
-LLL print responses in LDIF format without comments
and version
-M enable Manage DSA IT control (-MM to make critical)
-P version protocol version (default: 3)
-s scope one of base, one, sub or children (search scope)
-S attr sort the results by attribute `attr'
-t write binary values to files in temporary directory
-tt write all values to files in temporary directory
-T path write files to directory specified by path (default: /tmp)
-u include User Friendly entry names in the output
-z limit size limit (in entries, or "none" or "max") for search
Common options:
-d level set LDAP debugging level to `level'
-D binddn bind DN
-e [!] <ext>[=<extparam>] general extensions (! indicates criticality)
[!] assert=<filter> (RFC 4528; a RFC 4515 Filter string)
[!] authzid=<authzid> (RFC 4370; "dn:<dn>" or "u:<user>")
[!] chaining[=<resolveBehavior>[/<continuationBehavior>]]
one of "chainingPreferred", "chainingRequired",
"referralsPreferred", "referralsRequired"
[!] manageDSAit (RFC 3296)
[!] noop
ppolicy
[!] postread[=<attrs>] (RFC 4527; comma-separated attr list)
[!] preread[=<attrs>] (RFC 4527; comma-separated attr list)
[!] relax
[!] sessiontracking
abandon, cancel, ignore (SIGINT sends abandon/cancel,
or ignores response; if critical, doesn't wait for SIGINT.
not really controls)
-h host LDAP server
-H URI LDAP Uniform Resource Identifier(s)
-I use SASL Interactive mode
-n show what would be done but don't actually do it
-N do not use reverse DNS to canonicalize SASL host name
-O props SASL security properties
-o <opt>[=<optparam>] general options
nettimeout=<timeout> (in seconds, or "none" or "max")
ldif-wrap=<width> (in columns, or "no" for no wrapping)
-p port port on LDAP server
-Q use SASL Quiet mode
-R realm SASL realm
-U authcid SASL authentication identity
-v run in verbose mode (diagnostics to standard output)
-V print version info (-VV only)
-w passwd bind password (for simple authentication)
-W prompt for bind password
-x Simple authentication
-X authzid SASL authorization identity ("dn:<dn>" or "u:<user>")
-y file Read password from file
-Y mech SASL mechanism
-Z Start TLS request (-ZZ to require successful response)
The command is as follows:
The query results are as follows:
Query all users:
LDAP noun explanation
Objectclass
LDAP object class is the data model built into LDAP. Each objectClass has its own data structure, for example, we have an objectClass called "Phone Book", which will definitely have many built-in attributes, such as name (uid), ID number (uidNumber), unit name (gid), home address (homeDirectory), etc., at the same time, there is also an objectClass called "Classmate Record", which has a "phone book" Some attributes (such as uid, homeDirectory) will also have attributes that are not in the "phone book" (such as description, etc.).
Entry
An entry can be called an entry, an entry is a record, a basic storage unit in LDAP; It can also be thought of as a collection of DNs and a set of attributes. Note that an entry can contain multiple objectClasses, for example, zhang3 can exist in the "Phone Book" or in the "Classmate Record" at the same time.
DN
Distinguished Name, the unique distinguished name of the entry in LDAP, a complete DN spelling: uid=zhang3, ou=People, dc=163, dc=com. Only the entry in LDAP is unique by the LDAP Server.
LDAP Search filter
Use filter to search for LDAP. Filter is generally composed of a unit such as (attribute=value), for example: (&(uid=ZHANGSAN)(objectclass=person)) indicates that the LDAP Entry of the search user is ZHANGSAN. Another example is: (&(|( uid= ZHANGSAN)(uid=LISI))(objectclass=person)), indicating that the search for a user with a search id is ZHANGSAN, or LISI; You can also use * to represent any value, such as (uid=ZHANG*SAN), and search for entries with uid values starting with ZHANG and ending with SAN. Furthermore, according to different LDAP attribute matching rules, there can be a Filter as follows: (&(createtimestamp>=20050301000000)(createtimestamp<=20050302000000)), which indicates that the search creation time is between 20050301000000 and 20050302000000.
In Filter, "&" means "and"; “!” means "not"; “|” means "or". Depending on the matching rules, we can use "=", "~=", ">=", and "<=".
Base DN
A Base DN can be "dc=163,dc=com" or "dc=People,dc=163,dc=com". Since LDAP is a tree data structure, the search will start from BaseDN after specifying the basedn, and we can specify the search scope as: only search basedn (base), basedn direct sub level (one level), and basedn all sub tree level.
objectClass
In LDAP, an entry must contain an objectClass attribute and be assigned at least one value. Each value will be used as a template for data storage by an LDAP entry; The template contains an attribute that the entry must be assigned and an optional attribute. objectClass has a strict hierarchy, with top and alias at the top. For example, the objectClass of organizationalPerson is subordinate to person, and person is subordinate to top.
objectClass can be divided into the following 3 categories:
Structural: such as person and organizationUnit;
Auxiliary: such as extensibeObject;
Abstract: For example, the abstract objectClass cannot be used directly.
There are many objectClasses defined in the OpenLDAP schema, and the names of some commonly used objectClasses are listed below.
- account
- alias
- dcobject
- domain
- ipHost
- organization
- organizationalRole
- organizationalUnit
- person
- organizationalPerson
- inetOrgPerson
- residentialPerson
- posixAccount
- posixGroup
ObjectClass is a collection of attributes, and LDAP encapsulates many common objects in human organizations and encapsulates them into object classes. For example, personnel include surname (sn), first name (cn), telephone number (telephoneNumber), password (userPassword) and other attributes, and organizationalPerson is the inheritance class of person, in addition to the above attributes, it also includes title, postal code (postalCode), and mailing address (postalAddress) and other attributes.
Item types can be easily defined through object classes. Each entry can directly inherit multiple object classes, which inherits various properties. If there are 2 object classes with the same attribute, only 1 attribute will be retained after the entry is inherited. The object class also specifies which properties are basic information and must contain (Must Required): which properties are extended information and can contain (May or Optional).
There are three types of object classes: Structural, Abstract, and Auxiliary. Structural types are the most basic types, which specify the basic properties of the object body, and each entry belongs to and belongs to only one structural object class. Abstract types can be structural types or other abstract type parents, which organize the common parts of object properties together, called templates for other classes, and entries cannot directly integrate abstract object classes. The auxiliary type specifies the extended properties of the object entity. Although each bar belongs to only one structural object class, it can belong to multiple auxiliary object classes at the same time.
The object class itself can inherit each other, so the root class of the object class is the top abstract object class. Taking the commonly used types of people as an example, their inheritance relationship is as shown in the figure:
The built-in attributes of accout are: userid, description, host, localityName, organizationName, organizationalUnitName, seeAlso;
The built-in attributes of inetOrgPerson are cn, sn, description, seeAlso, telephoneNumber, userPassword, destinationIndicator, facsimileTelephoneNumber, internationaliSDNNumber, l, ou, physicalDeliveryOfficeName、postOfficeBox、postalAddress、postalCode、preferredDeliveryMethod、registeredAddress、st、street、telephoneNumber、teletexTerminalIdentifier、 telexNumber、title、x121Address、audio、usinessCategory、carLicense、departmentNumber、isplayName、employeeNumber、employeeType、givenName、homePhone、homePostalAddress、initials、 jpegPhoto, labeledURI, mail, manager, mobile, o, pager, photo, preferredLanguage, roomNumber, secretary, uid, userCertificate, etc.;
As you can see, accout only presets a few necessary and useful attributes (it is definitely enough to complete the login verification), while inetOrgPerson has a lot of built-in attributes, such as phone number, mobile phone number, street address, email number, email address, room number, avatar, manager, employee number, etc.
Therefore, when configuring LDAP, it is recommended to set the objectClass type to accout if it is only for the purpose of verifying login, and to set objectClass to inetOrgPerson if you want to create a large and comprehensive treasure trove of employee information
Here I usually use 'inetOrgPerson', 'posixAccount', 'shadowAccount'.
The required attributes of account are userid, while the required attributes of posixAccount are cn, gidNumber, homeDirectory, uid, uidNumber; The required attribute of shadowAccount is uid, and the optional attributes include shadowExpire, shadowInactive, shadowMax, shadowMin, userPassword, etc. The top required property is objectClass (it can be seen that top and other objectClasses are inherited relationships).
Attribute
Attributes are similar to variables in programming and can be assigned. Many commonly used attributes are declared in OpenLDAP (users can also define their own attributes). Common Attribute meanings are as follows:
- c: Country.
- cn:common name, which refers to the name of an object. If it refers to a person, its full name needs to be used.
- dc:domain component, often used to refer to a part of a domain name.
- givenName: refers to a person's name, not a surname.
- l: Refers to a place name, such as the name of a city or other geographical area.
- mail: Email address.
- o:organizationName, which refers to the name of an organization.
- ou:organizationalUnitName, which refers to the name of an organizational unit.
- sn: surname, refers to a person's surname.
- telephoneNumber: The phone number, which should carry the code of the country it is in.
Tip: objectClass is a special Attribute that contains other used Attributes as well as itself.
For different objectClasses, there are usually some required property values and some optional property values. For example, you can use the objectClass of person to represent an entry for a user in the system, and the user in the system usually needs to have some information such as name, phone number, password, description, etc. As shown in the image below, for person, set the user's first and last name via cn and sn, which is mandatory, while other attributes are optional.
The following is a list of some commonly used objectClass requirements that are required.
- account：userid。
- organization：o。
- person: cn and sn.
- organizationalPerson: Same as person.
- organizationalRole：cn。
- organizationUnit：ou。
- posixGroup：cn、gidNumber。
- posixAccount：cn、gidNumber、homeDirectory、uid、uidNumber。
(End)
|
Posted on 6/23/2020 10:34:54 PM
|
|
|
|
Posted on 5/19/2023 11:23:09 AM