OpenLDAP-kommandooppsummering
- ldapsearch: Søk etter OpenLDAP-katalogtre-oppføringer.
- ldapadd: Legger til katalogtreoppføringer via LDIF-format.
- ldapdelete: Sletter OpenLDAP-katalogtreoppføringer.
- ldapmodify: Endre OpenLDAP-katalogtreet.
- ldapwhoami: Validerer identiteten til OpenLDAP-brukere.
- ldapmodrdn: Vurderer OpenLDAP-katalogtreets DN-oppføring.
- ldapcompare: Bestemmer om DN-verdien og den angitte parameterverdien tilhører samme oppføring.
- ldappasswd: Endre brukeroppføringen i OpenLDAP-katalogtreet for å oppnå en passordtilbakestilling.
- slaptest: Verifiser filen slapd.conf eller cn=konfigurasjonsmappe.
- slapindex: Oppretter en OpenLDAP-katalogtreindeks for å gi spørringseffektivitet.
- slapcat: Konverterer data til LDIF-filer for OpenLDAP.
ldapadd-kommandoen
Alternativer | beskrivelse | -x | Utfør enkel autentisering | -D | DN-en som brukes til å binde serveren | -h | Adressen til katalogtjenesten | -w | Bind DN-passord | -f | Filer som bruker LDIF-filer for oppføringstillegg |
Først forbereder vi en test.ldif-fil med følgende kommando:
Innholdet 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
Legg til kommandoer som følger:
Etter at passordet er skrevet inn, legges det til, som vist i figuren nedenfor:
ldapmodifie-kommandoen
ldapmodified-kommandoen er fast og implementerer hovedsakelig ulike modifikasjonsfunksjoner gjennom konfigurasjonsfiler.
Filen demo.ldif er som følger, noe som betyr at uidNumber-parameteren til brukeren uid=xzz er endret.
ldappasswd-kommando
ldappasswd åpner en tilkobling til LDAP-serveren og endrer passordet til inngangen.
Alternativer | beskrivelse | -x | Utfør enkel autentisering | -D | DN-en som brukes til å binde serveren | -w | Bind DN-passord | -S | Skriv inn passordet når du blir bedt om det | -s | Pass for å sette passordet til Pass | -a | Pass satte Old Passwd til Pass | -A | Prompt innstilling av gammel passwd | -H | refererer til serveren som skal bindes | -Jeg | Bruk SASL-sesjonsmetoden |
ldapsearch-kommandoen
LDAP-søkekommando
[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økefilter
Attributter Hvitspace-separert liste over attributtbeskrivelser
som kan inkludere:
1.1 Ingen egenskaper
* alle brukerattributter
+ alle operative attributter
Søkealternativer:
-en deref av aldri (standard), alltid, søk eller finn
-A henter kun attributtnavn (ingen verdier)
-b basert på base DNS for søk
-c kontinuerlig driftsmodus (ikke stopp ved feil)
-E [!] <ext>[=<extparam>] søkeutvidelser (! indikerer kritikalitet)
[!] domainScope (domeneomfang)
!dontUseCopy (ikke bruk Copy)
[!] mv=<filter> (RFC 3876 filter for matchede verdier)
[!] pr=<size>[/prompt|noprompt] (RFC 2696 sidede resultater/prompt)
[!] sss=[-]<attr[:OID]>[/[-]<attr[:OID]>...]
(RFC 2891 serversortering)
[!] underoppføringer[=sann|falsk] (RFC 3672 underoppføringer)
[!] sync=ro[/<cookie>] (RFC 4533 LDAP Sync refreshOnly)
rp[/<cookie>][/<slimit>] (refreshAndPersist)
[!] vlv=<before>/<after>(/<offset><count>/|:<value>)
(ldapv3-vlv-09 virtuelle listevisninger)
[!] deref=derefAttr:attr[,...] [; derefAttr:attr[,...] [; ...]]
[!] <oid>[=:<b64value>] (generisk kontroll; ingen responshåndtering)
-f filleseoperasjoner fra 'fil'
-F-prefiks URL-prefiks for filer (standard: file:///tmp/)
-l begrenser tidsgrensen (i sekunder, eller "ingen" eller "maks") for søk
-L-utskriftssvar i LDIFv1-format
-LL skriver ut svar i LDIF-format uten kommentarer
-LLL skriver ut svar i LDIF-format uten kommentarer
og versjon
-M aktiver Administrer DSA IT-kontroll (-MM for å gjøre kritisk)
-P-versjon protokollversjon (standard: 3)
-s scope én av base, one, sub eller children (søkescope)
-S attr, sorter resultatene etter attributt 'attr'
-t skriver binære verdier til filer i en midlertidig mappe
-tt Skriv alle verdier til filer i en midlertidig mappe
-T sti skriv filer til katalog spesifisert av sti (standard: /tmp)
-u inkluderer brukervennlige oppføringsnavn i utdataene
-z grensestørrelse (i oppføringer, eller "ingen" eller "maks") for søk
Vanlige alternativer:
-d nivå sett LDAP-feilsøkingsnivå til 'nivå'
-D binddn bind DN
-e [!] <ext>[=<extparam>] generelle utvidelser (! indikerer kritikalitet)
[!] assert=<filter> (RFC 4528; en RFC 4515 filterstreng)
[!] authzid=<authzid> (RFC 4370; "dn:<dn>" eller "u:<user>")
[!] Kjede[=<resolveBehavior>[/<continuationBehavior>]]
en av «chainingForetrekket», «chainingRequired»,
"henvisningerForetrukket", "henvisninger" kreves"
[!] manageDSAit (RFC 3296)
[!] Nei, nei
Ppolicy
[!] postread[=<attrs>] (RFC 4527; komma-separert ATTR-liste)
[!] forhåndsleset[=<attrs>] (RFC 4527; komma-separert ATTR-liste)
[!] Slapp av
[!] Sessiontracking
abandon, cancel, ignorer (SIGINT sender abandon/cancel,
eller ignorerer responsen; hvis kritisk, vent ikke på SIGINT.
ikke egentlig kontroller)
-h host LDAP-server
-H URI LDAP Uniform Resource Identifier(s)
-Jeg bruker SASL interaktiv modus
-n vis hva som ville blitt gjort, men ikke gjør det egentlig
-N ikke bruk omvendt DNS for å kanonisere SASL-vertsnavn
-O props SASLs sikkerhetsegenskaper
-o <opt>[=<optparam>] generelle alternativer
NetTimeout=<timeout> (i sekunder, eller "ingen" eller "maks")
ldif-wrap=<width> (i kolonner, eller "no" for ingen wrapping)
-p portport på LDAP-server
-Q bruk SASL stille modus
-R-riket SASL-riket
-U authcid SASL-autentiseringsidentitet
-v kjører i verbose-modus (diagnostikk til standardutgang)
-Informasjon om V-trykt versjon (-kun VV)
-w passwd-bindepassord (for enkel autentisering)
-W-prompt for bindepassord
-x Enkel autentisering
-X autentisering SASL-autorisasjonsidentitet ("dn:<dn>" eller "u:<user>")
-y fil Les passord fra fil
-Y mech SASL-mekanisme
-Z Start TLS-forespørsel (-ZZ krever vellykket respons)
Kommandoen er som følger:
Søkeresultatene er som følger:
Spør alle brukere:
LDAP-substantivforklaring
Objektklasse
LDAP-objektklassen er datamodellen som er innebygd i LDAP. Hver objectClass har sin egen datastruktur, for eksempel har vi en objectClass kalt "Phone Book", som definitivt vil ha mange innebygde attributter, som navn (uid), ID-nummer (uidNumber), enhetsnavn (gid), hjemmeadresse (homeDirectory) osv., samtidig finnes det også en objectClass kalt "Classmate Record", som har en "telefonkatalog" Noen attributter (som uid, homeDirectory) vil også ha attributter som ikke finnes i "telefonkatalogen" (som beskrivelse, osv.).
Bidrag
En oppføring kan kalles en oppføring, en oppføring er en post, en grunnleggende lagringsenhet i LDAP; Det kan også betraktes som en samling av DN-er og et sett med attributter. Merk at en oppføring kan inneholde flere objectClasses, for eksempel kan zhang3 eksistere i "Telefonkatalogen" eller i "Klassekameratregisteret" samtidig.
DN
Distinguished Name, det unike distinguished navnet på oppføringen i LDAP, en komplett DN-stavemåte: uid=zhang3, ou=People, dc=163, dc=com. Kun oppføringen i LDAP er unik for LDAP-serveren.
LDAP-søkefilter
Bruk filter for å søke etter LDAP. Filter består vanligvis av en enhet som (attributt=verdi), for eksempel: (&(uid=ZHANGSAN)(objektklasse=person)) indikerer at LDAP-oppføringen til søkebrukeren er ZHANGSAN. Et annet eksempel er: (&(|( uid= ZHANGSAN)(uid=LISI))(objectclass=person)), noe som indikerer at søket etter en bruker med søke-ID er ZHANGSAN, eller LISI; Du kan også bruke * for å representere hvilken som helst verdi, som (uid=ZHANG*SAN), og søke etter oppføringer med uid-verdier som starter med ZHANG og slutter med SAN. Videre, ifølge ulike regler for LDAP-attributtmatching, kan det finnes et filter som følger: (&(createtimestamp>=20050301000000)(createtimestamp<=20050302000000)), som indikerer at søketiden er mellom 20050301000000 og 20050302000000.
I Filter betyr "&" "og"; “!” betyr "ikke"; “|” betyr "eller". Avhengig av matchingsreglene kan vi bruke "=", "~=", ">=", og "<=".
Grunnleggende DN
En grunnleggende DN kan være "dc=163,dc=com" eller "dc=Folk,dc=163,dc=com". Siden LDAP er en tre-datastruktur, starter søket fra BaseDN etter at basedn er spesifisert, og vi kan spesifisere søkeomfanget som: kun søk basert på basedn (base), basedn direkte undernivå (ett nivå), og basedn på alle deltre-nivåer.
objectClass
I LDAP må en oppføring inneholde et objectClass-attributt og tildeles minst én verdi. Hver verdi vil bli brukt som mal for datalagring av en LDAP-oppføring; Malen inneholder et attributt som oppføringen må tildeles, samt et valgfritt attributt. objectClass har et strengt hierarki, med top og alias øverst. For eksempel er objektKlassen til organisatoralPerson underordnet person, og person er underordnet topp.
objectClass kan deles inn i følgende 3 kategorier:
Struktur: slik som person og organisasjonEnhet;
Hjelpeverktøy: slik som extensibeObject;
Abstrakt: For eksempel kan ikke abstract objectClass brukes direkte.
Det finnes mange objectClasses definert i OpenLDAP-skjemaet, og navnene på noen vanlig brukte objectClasses er listet opp nedenfor.
- Beretning
- Alias
- dcobject
- Domene
- ipHost
- Organisasjon
- organisatorisk rolle
- organisatorisk enhet
- person
- organisatorisk person
- inetOrgPerson
- BoligPersonperson
- posixAccount
- posixGroup
ObjectClass er en samling attributter, og LDAP kapsler inn mange vanlige objekter i menneskelige organisasjoner og kapsler dem inn i objektklasser. For eksempel inkluderer ansatte etternavn (sn), fornavn (cn), telefonnummer (telephoneNumber), passord (userPassword) og andre attributter, og organizationalPerson er arveklassen til personen, i tillegg til de ovennevnte attributtene, inkluderer den også tittel, postnummer (postnummer) og postadresse (postadresse) og andre egenskaper.
Gjenstandstyper kan enkelt defineres gjennom objektklasser. Hver oppføring kan direkte arve flere objektklasser, som arver ulike egenskaper. Hvis det finnes to objektklasser med samme attributt, vil bare én attributt beholdes etter at oppføringen er arvet. Objektklassen spesifiserer også hvilke egenskaper som er grunnleggende informasjon og må inneholde (Må kreves): hvilke egenskaper som er utvidet informasjon og kan inneholde (Kan eller Valgfritt).
Det finnes tre typer objektklasser: Strukturell, Abstrakt og Hjelpeobjekt. Strukturelle typer er de mest grunnleggende typene, som spesifiserer de grunnleggende egenskapene til objektkroppen, og hver oppføring tilhører og tilhører kun én strukturell objektklasse. Abstrakte typer kan være strukturelle typer eller andre abstrakte typeforeldre, som organiserer de felles delene av objektegenskaper sammen, kalt maler for andre klasser, og oppføringer kan ikke direkte integrere abstrakte objektklasser. Hjelpetypen spesifiserer de utvidede egenskapene til objektentiteten. Selv om hver strek tilhører kun én strukturell objektklasse, kan den tilhøre flere hjelpeobjektklasser samtidig.
Objektklassen selv kan arve hverandre, så rotklassen til objektklassen er den øverste abstrakte objektklassen. Tar vi de mest brukte typene mennesker som eksempel, er deres arveforhold som vist i figuren:
De innebygde attributtene til accout er: userid, description, host, localityName, organizationName, organizationalUnitName, se Også;
De innebygde attributtene til inetOrgPerson er cn, sn, beskrivelse, seOgså, 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 osv.;
Som du ser, forhåndsinnstiller accout bare noen få nødvendige og nyttige attributter (det er definitivt nok til å fullføre innloggingsverifiseringen), mens inetOrgPerson har mange innebygde attributter, som telefonnummer, mobilnummer, gateadresse, e-postnummer, e-postadresse, romnummer, avatar, leder, ansattnummer osv.
Derfor anbefales det, når du konfigurerer LDAP, å sette objectClass-typen til accout hvis det kun er for å verifisere innlogging, og å sette objectClass til inetOrgPerson hvis du ønsker å lage en stor og omfattende skattkiste av ansattinformasjon
Her bruker jeg vanligvis 'inetOrgPerson', 'posixAccount', 'shadowAccount'.
De nødvendige attributtene for kontoen er userid, mens de nødvendige attributtene for posixAccount er cn, gidNumber, homeDirectory, uid, uidNumber; Den nødvendige attributten til shadowAccount er uid, og de valgfrie attributtene inkluderer shadowExpire, shadowInactive, shadowMax, shadowMin, userPassword, osv. Den øverste nødvendige egenskapen er objectClass (det kan sees at top og andre objectClasses er arvede relasjoner).
Attributt
Attributter ligner på variabler i programmering og kan tildeles. Mange vanlige attributter er deklarert i OpenLDAP (brukere kan også definere sine egne attributter). Vanlige attributtbetydninger er som følger:
- c: Land.
- CN: Common Name, som refererer til navnet på et objekt. Hvis det refererer til en person, må det fulle navnet brukes.
- DC:Domenekomponent, ofte brukt for å referere til en del av et domenenavn.
- Fornavn: refererer til en persons navn, ikke et etternavn.
- l: Refererer til et stedsnavn, som navnet på en by eller et annet geografisk område.
- post: E-postadresse.
- o:organizationName, som refererer til navnet på en organisasjon.
- ou:organisatoriskEnhetsnavn, som refererer til navnet på en organisasjonsenhet.
- SN: Etternavn, refererer til en persons etternavn.
- telephoneNumber: Telefonnummeret, som skal inneholde koden til landet det befinner seg i.
Tips: objectClass er en spesiell attributt som inneholder andre brukte attributter i tillegg til seg selv.
For ulike objectClasses finnes det vanligvis noen nødvendige egenskapsverdier og noen valgfrie egenskapsverdier. For eksempel kan du bruke objectClass of person for å representere en oppføring for en bruker i systemet, og brukeren i systemet må vanligvis ha informasjon som navn, telefonnummer, passord, beskrivelse osv. Som vist på bildet under, for person, sett brukerens for- og etternavn via cn og sn, som er obligatorisk, mens andre attributter er valgfrie.
Følgende er en liste over noen ofte brukte objectClass-krav som er nødvendige.
- account:userid。
- organisasjon:o。
- PERSON: CN og SN.
- organisatorisk Person: Samme som person.
- organizationalRole:cn。
- organizationUnit:ou。
- posixGroup:cn、gidNumber。
- posixAccount:cn、gidNumber、homeDirectory、uid、uidNumber。
(Slutt)
|
Publisert på 23.06.2020 22:34:54
|
|
|
|
Publisert på 19.05.2023 11:23:09