OpenLDAP-kommandooversigt
- ldapsearch: Søg efter OpenLDAP-katalogtræ-poster.
- ldapadd: Tilføjer katalogtræ-poster via LDIF-format.
- ldapdelete: Sletter OpenLDAP-mappetræposter.
- ldapmodify: Ændr OpenLDAP-mappetræets post.
- ldapwhoami: Validerer identiteten af OpenLDAP-brugere.
- ldapmodrdn: Vurderer OpenLDAP-mappetræets DN-post.
- ldapcompare: Afgør, om DN-værdien og den specificerede parameterværdi tilhører samme post.
- ldappasswd: Ændr OpenLDAP-mappetræets brugerpost for at opnå en adgangskodenulstilling.
- slaptest: Verificér filen slapd.conf eller cn=konfigurationsmappe.
- slapindex: Opretter et OpenLDAP-katalogtræindeks for at sikre forespørgselseffektivitet.
- slapcat: Konverterer data til LDIF-filer til OpenLDAP.
ldapadd-kommandoen
Muligheder | beskrivelse | -x | Udfør simpel autentificering | -D | DN'en, der bruges til at binde serveren | -h | Adressen på katalogtjenesten | -w | Bind DN-adgangskode | -f | Filer, der bruger LDIF-filer til tilføjelse af indgange |
Først forbereder vi en test.ldif-fil med følgende kommando:
Indholdet er som følger:
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
Tilføj kommandoer som følger:
Efter at have indtastet adgangskoden, tilføjes den med succes, som vist i figuren nedenfor:
ldapmodifie-kommandoen
ldapmodifie-kommandoen er fast og implementerer hovedsageligt forskellige modifikationsfunktioner gennem konfigurationsfiler.
Filen demo.ldif er som følger, hvilket betyder, at uidNumber-parameteren for brugeren uid=xzz ændres.
ldappasswd-kommandoen
ldappasswd åbner en forbindelse til LDAP-serveren og ændrer adgangskoden til indgangen.
Muligheder | beskrivelse | -x | Udfør simpel autentificering | -D | DN'en, der bruges til at binde serveren | -w | Bind DN-adgangskode | -S | Indtast adgangskoden, når du bliver bedt om det | -s | Pass for at sætte adgangskoden til pass | -a | Aflevering satte gamle PassWD til at passere | -A | Prompt indstillingen af den gamle passwd | -H | henviser til den server, der skal bindes | -Jeg | Brug SASL-sessionsmetoden |
ldapsearch-kommandoen
ldap søgekommando
[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-kompatibel LDAP-søgefilter
Attributter Whitespace-separeret liste over attributbeskrivelser
som kan omfatte:
1.1 Ingen attributter
* alle brugerattributter
+ alle operationelle attributter
Søgemuligheder:
-en deref en af aldrig (standard), altid, søg eller find
-A henter kun attributnavne (ingen værdier)
-b baseret dn base dn til søgning
-c kontinuerlig driftstilstand (stop ikke ved fejl)
-E [!] <ext>[=<extparam>] søgeudvidelser (! angiver kritikalitet)
[!] domæneomfang (domæneomfang)
!dontUseCopy (brug ikke Copy)
[!] mv=<filter> (RFC 3876 matchede værdier-filter)
[!] pr=<size>[/prompt|noprompt] (RFC 2696 pagede resultater/prompt)
[!] sss=[-]<attr[:OID]>[/[-]<attr[:OID]>...]
(RFC 2891 serverside sortering)
[!] underposters[=true|false] (RFC 3672 subposters)
[!] sync=ro[/<cookie>] (RFC 4533 LDAP Sync refreshOnly)
rp[/<cookie>][/<slimit>] (refreshAndPersist)
[!] vlv=<before>/<after>(/<offset>/<count>|:<value>)
(LDAPav3-VLV-09 virtuelle listevisninger)
[!] deref=derefAttr:attr[,...] [; derefAttr:attr[,...] [; ...]]
[!] <oid>[=:<b64value>] (generisk kontrol; ingen responshåndtering)
-f fillæseoperationer fra 'fil'
-F-præfiks URL-præfiks for filer (standard: file:///tmp/)
-l begrænser tidsgrænsen (i sekunder, eller "ingen" eller "maks") for søgning
-L-print svar i LDIFv1-format
-LL udskriver svar i LDIF-format uden kommentarer
-LLL udskriver svar i LDIF-format uden kommentarer
og version
-M aktiver Manage DSA IT-kontrol (-MM for at gøre kritisk)
-P-version protokolversion (standard: 3)
-s scope én af base, one, sub eller children (søgescope)
-S attr sorter resultaterne efter attribut 'attr'
-t skriver binære værdier til filer i en midlertidig mappe
-tt skriv alle værdier til filer i en midlertidig mappe
-T sti skrivefiler til mappe specificeret af sti (standard: /tmp)
-u inkluder brugervenlige indgangsnavne i outputtet
-z grænse for størrelsesgrænsen (i poster, eller "ingen" eller "max") for søgning
Almindelige muligheder:
-d niveau sæt LDAP debugging-niveau til 'niveau'
-D binddn bind DN
-e [!] <ext>[=<extparam>] generelle udvidelser (! angiver kritikalitet)
[!] assert=<filter> (RFC 4528; en RFC 4515 filterstreng)
[!] authzid=<authzid> (RFC 4370; "dn:<dn>" eller "u:<user>")
[!] kæde[=<resolveBehavior>[/<continuationBehavior>]]
en af "chainingForeget", "chainingRequired",
"henvisningerForetrukken", "henvisningerPåkrævet"
[!] manageDSAit (RFC 3296)
[!] Nej
Ppolicy
[!] postread[=<attrs>] (RFC 4527; komma-separeret attr-liste)
[!] forudlæst[=<attrs>] (RFC 4527; komma-separeret attr-liste)
[!] Slap af
[!] sessiontracking
abandon, cancel, ignorer (SIGINT sender abandon/cancel,
eller ignorerer svar; hvis kritisk, venter ikke på SIGINT.
ikke rigtig kontrol.
-h host LDAP-server
-H URI LDAP Uniform Resource Identifier(s)
-Jeg bruger SASL Interactive-tilstand
-n vis, hvad der ville blive gjort, men gør det ikke rent faktisk
-N brug ikke reverse DNS til at kanonificere SASL-værtsnavnet
-O props SASL sikkerhedsegenskaber
-o <opt>[=<optparam>] generelle muligheder
NetTimeout=<timeout> (i sekunder, eller "ingen" eller "maks")
ldif-wrap=<width> (i kolonner, eller "nej" for ingen wrapping)
-p portport på LDAP-server
-Q brug SASL Stille tilstand
-R-riget SASL-riget
-U authcid SASL-autentificeringsidentitet
-v kører i verbose-tilstand (diagnostik til standardoutput)
-V print version info (-VV kun)
-w passwd bind adgangskode (til simpel autentificering)
-W-prompt for bindeadgangskode
-x Simpel autentificering
-X authzid SASL-autorisationsidentitet ("dn:<dn>" eller "u:<user>")
-y fil Læs adgangskode fra fil
-Y mech SASL-mekanisme
-Z Start TLS-anmodning (-ZZ kræver succesfuldt svar)
Kommandoen er som følger:
Forespørgselsresultaterne er som følger:
Forespørg alle brugere:
LDAP-substantivforklaring
Objektklasse
LDAP-objektklassen er datamodellen, der er indbygget i LDAP. Hver objectClass har sin egen datastruktur, for eksempel har vi en objectClass kaldet "Phone Book", som helt sikkert vil have mange indbyggede attributter, såsom navn (uid), ID-nummer (uidNumber), enhedsnavn (gid), hjemmeadresse (homeDirectory) osv., samtidig med at der også findes en objectClass kaldet "Classmate Record", som har en "telefonbog" Nogle attributter (såsom uid, homeDirectory) vil også have attributter, der ikke findes i "telefonbogen" (såsom beskrivelse osv.).
Indgang
En post kan kaldes en post, en post er en post, en grundlæggende lagringsenhed i LDAP; Det kan også betragtes som en samling af DN'er og et sæt attributter. Bemærk, at en post kan indeholde flere objectClasses, for eksempel kan zhang3 eksistere i "Telefonbogen" eller i "Classmate Record" på samme tid.
DN
Distinguished Name, det unikke distinguished navn for opslaget i LDAP, en komplet DN-stavemåde: uid=zhang3, ou=People, dc=163, dc=com. Kun posten i LDAP er unik for LDAP-serveren.
LDAP Søgefilter
Brug filter til at søge efter LDAP. Filter består generelt af en enhed såsom (attribut=værdi), for eksempel: (&(uid=ZHANGSAN)(objektklasse=person)) angiver, at LDAP-posten for søgebrugeren er ZHANGSAN. Et andet eksempel er: (&(|( uid= ZHANGSAN)(uid=LISI))(objectclass=person)), hvilket indikerer, at søgningen efter en bruger med et søge-id er ZHANGSAN, eller LISI; Du kan også bruge * til at repræsentere enhver værdi, såsom (uid=ZHANG*SAN), og søge efter poster med uid-værdier, der starter med ZHANG og slutter med SAN. Desuden kan der ifølge forskellige LDAP-attributmatchningsregler være et filter som følger: (&(createtimestamp>=20050301000000)(createtimestamp<=20050302000000)), hvilket angiver, at søgeoprettelsestiden er mellem 20050301000000 og 20050302000000.
I Filter betyder "&" "og"; “!” betyder "ikke"; “|” betyder "eller". Afhængigt af matchningsreglerne kan vi bruge "=", "~=", ">=", og "<=".
Base DN
En basis-DN kan være "dc=163,dc=com" eller "dc=People,dc=163,dc=com". Da LDAP er en trædatastruktur, starter søgningen fra BaseDN efter at have specificeret basedn, og vi kan specificere søgeomfanget som: kun søgebaseret baseret (base), baseret direkte underniveau (ét niveau) og basedn på alle undertræniveau.
objectClass
I LDAP skal en post indeholde en objectClass-attribut og tildeles mindst én værdi. Hver værdi vil blive brugt som skabelon for datalagring af en LDAP-post; Skabelonen indeholder en attribut, som posten skal tildeles, samt en valgfri attribut. objectClass har et strengt hierarki, hvor top og alias er øverst. For eksempel er objektklassen af organisatoralPerson underordnet person, og person er underordnet top.
objectClass kan opdeles i følgende 3 kategorier:
Strukturel: såsom person og organisation Enhed;
Hjælpeværktøj: såsom extensibeObject;
Abstrakt: For eksempel kan abstract objectClass ikke bruges direkte.
Der er mange objectClasses defineret i OpenLDAP-skemaet, og navnene på nogle almindeligt anvendte objectClasses er listet nedenfor.
- Beretning
- alias
- DCobject
- Domæne
- ipHost
- Organisation
- organisatorisk rolle
- organisatorisk enhed
- person
- organisatorisk person
- inetOrgPerson
- boligPerson
- posixAccount
- posixGroup
ObjectClass er en samling af attributter, og LDAP indkapsler mange almindelige objekter i menneskelige organisationer og indkapsler dem i objektklasser. For eksempel inkluderer personale efternavn (sn), fornavn (cn), telefonnummer (telephoneNumber), adgangskode (userPassword) og andre attributter, og organizationalPerson er arveklassen for personen; ud over ovenstående attributter inkluderer den også titel, postnummer (postnummer) og postadresse (postadresse) og andre egenskaber.
Genstandetyper kan nemt defineres gennem objektklasser. Hver post kan direkte arve flere objektklasser, som arver forskellige egenskaber. Hvis der er 2 objektklasser med samme attribut, vil kun 1 attribut blive bevaret, efter at indgangen er arvet. Objektklassen specificerer også, hvilke egenskaber der er grundlæggende information og skal indeholde (Skal kræves): hvilke egenskaber der er udvidet information og kan indeholde (Kan eller Valgfrit).
Der findes tre typer objektklasser: Struktur, Abstrakt og Hjælpeobjekt. Strukturelle typer er de mest basale typer, som specificerer objektets grundlæggende egenskaber, og hver post tilhører og tilhører kun én strukturel objektklasse. Abstrakte typer kan være strukturelle typer eller andre abstrakte typeforældre, som organiserer de fælles dele af objektegenskaber sammen, kaldet skabeloner for andre klasser, og poster kan ikke direkte integrere abstrakte objektklasser. Hjælpetypen specificerer objektentitetens udvidede egenskaber. Selvom hver bar kun tilhører én strukturel objektklasse, kan den tilhøre flere hjælpeobjektklasser på samme tid.
Objektklassen selv kan arve hinanden, så rodklassen af objektklassen er den øverste abstrakte objektklasse. Hvis vi tager de almindeligt anvendte typer som eksempel, er deres arveforhold som vist i figuren:
De indbyggede attributter for accout er: userid, description, host, localityName, organizationName, organizationalUnitName, se Også;
De indbyggede attributter i inetOrgPerson er cn, sn, description, seAlso, telephoneNumber, userPassword, destinationIndicator, facsimileTelephoneNumber, internationaliSDNNumber, l, ou, physicalDeliveryOfficeName、postOfficeBox、postalAddress、postalCode、preferredDeliveryMethod、registeredAddress、st、street、telephoneNumber、teletexTerminalIdentifier、 telexNumber、title、x121Address、audio、usinessCategory、billicens、departmentNumber、isplayName、employeeNumber、employeeType、givenName、homePhone、homePostalAddress、initialer、 jpegPhoto, labeledURI, mail, manager, mobile, o, pager, photo, foretrukket sprog, roomNumber, sekretær, uid, userCertificate osv.;
Som du kan se, forudindstiller accout kun nogle få nødvendige og nyttige attributter (det er bestemt nok til at fuldføre loginverifikationen), mens inetOrgPerson har mange indbyggede attributter, såsom telefonnummer, mobilnummer, gadeadresse, e-mailadresse, e-mailadresse, værelsesnummer, avatar, leder, medarbejdernummer osv.
Derfor anbefales det, når man konfigurerer LDAP, at sætte objectClass-typen til accout, hvis det kun er med henblik på at verificere login, og at sætte objectClass til inetOrgPerson, hvis man ønsker at skabe en stor og omfattende skattekiste af medarbejderinformation
Her bruger jeg normalt 'inetOrgPerson', 'posixAccount', 'shadowAccount'.
De nødvendige attributter for kontoen er userid, mens de nødvendige attributter for posixAccount er cn, gidNumber, homeDirectory, uid, uidNumber; Den krævede attribut for shadowAccount er uid, og de valgfrie attributter inkluderer shadowExpire, shadowInactive, shadowMax, shadowMin, userPassword osv. Den øverste krævede egenskab er objectClass (det kan ses, at top og andre objectClasses er arvede relationer).
Attribut
Attributter ligner variabler i programmering og kan tildeles. Mange almindeligt anvendte attributter er deklareret i OpenLDAP (brugere kan også definere deres egne attributter). Almindelige attributbetydninger er som følger:
- c: Land.
- CN: Common Name, som refererer til navnet på et objekt. Hvis det refererer til en person, skal det fulde navn bruges.
- DC:Domænekomponent, ofte brugt til at henvise til en del af et domænenavn.
- givetNavn: henviser til en persons navn, ikke et efternavn.
- l: Henviser til et stednavn, såsom navnet på en by eller et andet geografisk område.
- post: E-mailadresse.
- o:organizationName, som refererer til navnet på en organisation.
- ou:organisatoralEnhedNavn, som refererer til navnet på en organisatorisk enhed.
- SN: efternavn henviser til en persons efternavn.
- telephoneNumber: Telefonnummeret, som bør indeholde koden for det land, det befinder sig i.
Tip: objectClass er en særlig attribut, der indeholder andre anvendte attributter samt sig selv.
For forskellige objectClasses er der som regel nogle krævede ejendomsværdier og nogle valgfrie egenskabsværdier. For eksempel kan du bruge objectClass of person til at repræsentere en post for en bruger i systemet, og brugeren i systemet skal som regel have nogle oplysninger som navn, telefonnummer, adgangskode, beskrivelse osv. Som vist på billedet nedenfor, for person, sæt brugerens for- og efternavn via cn og sn, hvilket er obligatorisk, mens andre attributter er valgfrie.
Følgende er en liste over nogle almindeligt anvendte objectClass-krav, der er nødvendige.
- account:userid。
- organisation:o。
- Person: CN og SN.
- organisatorisk Person: Samme som person.
- organizationalRole:cn。
- organizationUnit:ou。
- posixGroup:cn、gidNumber。
- posixAccount:cn、gidNumber、homeDirectory、uid、uidNumber。
(Slut)
|
Opslået på 23/06/2020 22.34.54
|
|
|
|
Opslået på 19/05/2023 11.23.09