OpenLDAP-kommandosammanfattning
- ldapsearch: Sök efter OpenLDAP-katalogträdsposter.
- ldapadd: Lägger till katalogträdsposter via LDIF-format.
- ldapdelete: Tar bort OpenLDAP-katalogträdposter.
- ldapmodify: Modifiera OpenLDAP-katalogträdets post.
- ldapwhoami: Validerar identiteten på OpenLDAP-användare.
- ldapmodrdn: Bedömer OpenLDAP-katalogträdets DN-post.
- ldapcompare: Avgör om DN-värdet och det specificerade parametervärdet tillhör samma post.
- ldappasswd: Modifiera OpenLDAP-katalogträdets användarpost för att uppnå en lösenordsåterställning.
- slaptest: Verifiera filen slapd.conf eller cn=konfigurationskatalogen.
- slapindex: Skapar ett OpenLDAP-katalogträdsindex för att ge sökeffektivitet.
- slapcat: Konverterar data till LDIF-filer för OpenLDAP.
ldapadd-kommandot
Alternativ | beskrivning | -x | Utför enkel autentisering | -D | DN:n som används för att binda servern | -h | Adressen till katalogtjänsten | -w | Bind DN-lösenordet | -f | Filer som använder LDIF-filer för att addera poster |
Först förbereder vi en test.ldif-fil med följande kommando:
Innehållet är som följer:
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
Lägg till kommandon enligt följande:
Efter att lösenordet har matats in läggs det till framgångsrikt, som visas i figuren nedan:
ldapmodifie-kommandot
Ldapmodified-kommandot är fast och implementerar främst olika modifieringsfunktioner via konfigurationsfiler.
Filen demo.ldif är följande, vilket innebär att parametern uidNumber för användaren uid=xzz är modifierad.
ldappasswd-kommandot
ldappasswd öppnar en anslutning till LDAP-servern och ändrar lösenordet för inmatningen.
Alternativ | beskrivning | -x | Utför enkel autentisering | -D | DN:n som används för att binda servern | -w | Bind DN-lösenordet | -S | Ange lösenordet när du blir tillfrågad | -s | pass för att ställa lösenordet till pass | -a | Pass satte Old Passwd att passa | -A | Prompt inställningen av gamla passwd | -H | syftar på servern som ska bindas | -Jag | Använd SASL-sessionsmetoden |
ldapsearch-kommandot
LDAP-sökkommando
[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ökfilter
attribut whitespace-separerad lista över attributbeskrivningar
vilket kan inkludera:
1.1 Inga attribut
* alla användarattribut
+ alla operativa attribut
Sökalternativ:
-en deref en av never (default), alltid, sök eller hitta
-A hämta endast attributnamn (inga värden)
-b baserad DNS bas-DNS för sökning
-c kontinuerligt driftläge (stanna inte vid fel)
-E [!] <ext>[=<extparam>] söktillägg (! indikerar kritikalitet)
[!] domänScope (domänområde)
!dontUseCopy (använd inte Copy)
[!] mv=<filter> (RFC 3876 matchade värden-filter)
[!] pr=<size>[/prompt|noprompt] (RFC 2696 sidiga resultat/prompt)
[!] sss=[-]<attr[:OID]>[/[-]<attr[:OID]>...]
(RFC 2891 serversortering)
[!] delposters[=true|false] (RFC 3672 subposters)
[!] sync=ro[/<cookie>] (RFC 4533 LDAP Sync refreshOnly)
rp[/<cookie>][/<slimit>] (refreshAndPersist)
[!] vlv=<before>/<after>(/<offset><count>/|:<value>)
(LDAPV3-VLV-09 virtuella listvyer)
[!] deref=derefAttr:attr[,...] [; derefAttr:attr[,...] [; ...]]
[!] <oid>[=:<b64value>] (generisk kontroll; ingen responshantering)
-f filläsningsoperationer från 'fil'
-F-prefix URL-prefix för filer (standard: file:///tmp/)
-l begränsar tidsgränsen (i sekunder, eller "ingen" eller "max") för sökning
-L-utskriftssvar i LDIFv1-format
-LL skriver ut svar i LDIF-format utan kommentarer
-LLL skriver ut svar i LDIF-format utan kommentarer
och version
-M aktivera Hantera DSA IT-kontroll (-MM för att göra kritisk)
-P-version protokollversion (standard: 3)
-s omfare ett av bas, ett, sub eller barn (sökområde)
-S attr sortera resultaten efter attribut 'attr'
-t skriver binära värden till filer i en temporär katalog
-tt skriv alla värden till filer i en temporär katalog
-T path skriv filer till katalog specificerad av path (standard: /tmp)
-u inkluderar användarvänliga postnamn i utdatan
-z-gränsstorleksgräns (i poster, eller "ingen" eller "max") för sökning
Vanliga alternativ:
-d nivå sätt LDAP-felsökningsnivån till 'nivå'
-D binddn bind DN
-e [!] <ext>[=<extparam>] allmänna utvidgningar (! indikerar kritikalitet)
[!] assert=<filter> (RFC 4528; en RFC 4515 filtersträng)
[!] authzid=<authzid> (RFC 4370; "dn:<dn>" eller "u:<user>")
[!] Kedja[=<resolveBehavior>[/<continuationBehavior>]]
en av "chainingPreferred", "chainingRequired",
"rekommendationerFöredraget", "rekommendationerKrävs"
[!] manageDSAit (RFC 3296)
[!] Nej
Ppolicy
[!] postread[=<attrs>] (RFC 4527; komma-separerad attr-lista)
[!] förläst[=<attrs>] (RFC 4527; komma-separerad attr-lista)
[!] Slappna av
[!] Sessiontracking
överge, avbryt, ignorera (SIGINT skickar övergiv/avbryt,
eller ignorerar svaret; om kritiskt är väntar den inte på SIGINT.
inte riktigt kontroller)
-h värd LDAP-server
-H URI LDAP Uniform Resource Identifier(s)
-Jag använder SASL interaktivt läge
-n visa vad som skulle göras men gör det inte på riktigt
-N använder inte omvänd DNS för att kanonisera SASL-värdnamnet
-O props SASL:s säkerhetsegenskaper
-o <opt>[=<optparam>] allmänna alternativ
NetTimeout=<timeout> (i sekunder, eller "ingen" eller "max")
ldif-wrap=<width> (i kolumner, eller "no" för ingen wrapping)
-p portport på LDAP-server
-Q använd SASL tyst läge
-R-riket SASL-riket
-U authcid SASL-autentiseringsidentitet
-v körs i verbose-läge (diagnostik till standardutgång)
-V-tryckt versionsinformation (-endast VV)
-w passwd bind lösenord (för enkel autentisering)
-W-prompt för bindningslösenord
-x Enkel autentisering
-X-authzid SASL-auktorisationsidentitet ("dn:<dn>" eller "u:<user>")
-y fil Läs lösenord från fil
-Y mech SASL-mekanism
-Z Start TLS-förfrågan (-ZZ kräver framgångsrikt svar)
Kommandot är följande:
Sökresultaten är följande:
Fråga alla användare:
LDAP-substantivförklaring
Objektklass
LDAP-objektklassen är datamodellen som är inbyggd i LDAP. Varje objektKlass har sin egen datastruktur, till exempel har vi en objektklass som heter "Telefonbok", som definitivt har många inbyggda attribut, såsom namn (uid), ID-nummer (uidNumber), enhetsnamn (gid), hemadress (homeDirectory) osv., samtidigt finns det också en objektklass som heter "Classmate Record", som har en "telefonkatalog" Vissa attribut (såsom uid, homeDirectory) har också attribut som inte finns i "telefonkatalogen" (såsom beskrivning, etc.).
Inträde
En post kan kallas en post, en post är en post, en grundläggande lagringsenhet i LDAP; Det kan också ses som en samling DN:er och en uppsättning attribut. Observera att en post kan innehålla flera objectClasses, till exempel kan zhang3 finnas i "Telefonkatalogen" eller i "Klasskamratsregister" samtidigt.
DN
Distinguished Name, det unika distinguished namnet på posten i LDAP, en komplett DN-stavning: uid=zhang3, ou=People, dc=163, dc=com. Endast posten i LDAP är unik för LDAP-servern.
LDAP-sökfilter
Använd filter för att söka efter LDAP. Filter består vanligtvis av en enhet såsom (attribut=värde), till exempel: (&(uid=ZHANGSAN)(objektklass=person)) indikerar att LDAP-posten för sökanvändaren är ZHANGSAN. Ett annat exempel är: (&(|( uid= ZHANGSAN)(uid=LISI))(objectclass=person)), vilket indikerar att sökningen efter en användare med sök-id är ZHANGSAN, eller LISI; Du kan också använda * för att representera vilket värde som helst, såsom (uid=ZHANG*SAN), och söka efter poster med uid-värden som börjar med ZHANG och slutar på SAN. Dessutom kan det, enligt olika LDAP-attributmatchningsregler, finnas ett filter enligt följande: (&(createtimestamp>=20050301000000)(createtimestamp<=20050302000000)), vilket indikerar att söktiden för skapande är mellan 20050301000000 och 20050302000000.
I Filter betyder "&" "och"; “!” betyder "inte"; “|” betyder "eller". Beroende på matchningsreglerna kan vi använda "=", "~=", ">=" och "<=".
Bas-DN
En bas-DN kan vara "dc=163,dc=com" eller "dc=People,dc=163,dc=com". Eftersom LDAP är en träddatastruktur startar sökningen från BaseDN efter att basedn specificerats, och vi kan specificera sökomfånget som: endast sökbaserad baserad (bas), baserad direkt undernivå (en nivå) och baserad på alla delträdsnivåer.
objectClass
I LDAP måste en post innehålla ett objectClass-attribut och tilldelas minst ett värde. Varje värde kommer att användas som mall för datalagring av en LDAP-post; Mallen innehåller ett attribut som posten måste tilldelas och ett valfritt attribut. objectClass har en strikt hierarki, med top och alias högst upp. Till exempel är objektklassen i organisatorisk person underordnad, och person är underordnad topp.
objectClass kan delas in i följande tre kategorier:
Strukturell: såsom person och organisation Enhet;
Hjälpfunktion: såsom extensibeObject;
Abstrakt: Till exempel kan abstract objectClass inte användas direkt.
Det finns många objectClasses definierade i OpenLDAP-schemat, och namnen på några vanligt använda objectClasses listas nedan.
- Kontot
- alias
- DC-objekt
- Domän
- ipHost
- Organisation
- organisatorisk roll
- organisatorisk enhet
- person
- organisatorisk person
- inetOrgPerson
- bostadsperson
- posixAccount
- posixGroup
ObjectClass är en samling attribut, och LDAP kapslar in många vanliga objekt i mänskliga organisationer och kapslar in dem i objektklasser. Till exempel inkluderar personal efternamn (sn), förnamn (cn), telefonnummer (telephoneNumber), lösenord (userPassword) och andra attribut, och organizationalPerson är arvsklassen för personen, utöver ovanstående attribut inkluderar den även titel, postnummer (postnummer) och postadress (postadress) och andra attribut.
Föremålstyper kan enkelt definieras genom objektklasser. Varje post kan direkt ärva flera objektklasser, som ärver olika egenskaper. Om det finns två objektklasser med samma attribut kommer endast ett attribut att behållas efter att posten ärvts. Objektklassen specificerar också vilka egenskaper som är grundläggande information och måste innehålla (Måste krävas): vilka egenskaper som är utökad information och kan innehålla (Kan eller Valfritt).
Det finns tre typer av objektklasser: Strukturella, Abstrakta och Hjälpklasser. Strukturella typer är de mest grundläggande typerna, som specificerar objektkroppens grundläggande egenskaper, och varje post tillhör och tillhör endast en strukturell objektklass. Abstrakta typer kan vara strukturella typer eller andra abstrakta typföräldrar, som organiserar de gemensamma delarna av objektegenskaper tillsammans, kallade mallar för andra klasser, och poster kan inte direkt integrera abstrakta objektklasser. Hjälptypen specificerar objektentitetens utökade egenskaper. Även om varje stång endast tillhör en strukturell objektklass, kan den tillhöra flera hjälpobjektklasser samtidigt.
Objektklassen kan själv ärva varandra, så rotklassen för objektklassen är den översta abstrakta objektklassen. Om vi tar de vanliga typerna av människor som exempel, är deras arvsrelation som visas i figuren:
De inbyggda attributen för accout är: userid, description, host, localityName, organizationName, organizationalUnitName, se Även;
De inbyggda attributen för inetOrgPerson är cn, sn, beskrivning, se också, telephoneNumber, userPassword, destinationIndicator, facsimileTelephoneNumber, internationaliSDNNumber, l, ou, physicalDeliveryOfficeName、postOfficeBox、postalAddress、postalCode、preferredDeliveryMethod、registeredAddress、st、street、telephoneNumber、teletexTerminalIdentifier、 telexNumber、title、x121Address、audio、usinessCategory、bilkörkort、avdelningsnummer、isplayName、employeeNumber、employeeType、givenName、homePhone、homePostalAddress、initialer、 jpegPhoto, labeledURI, mail, manager, mobile, o, pager, photo, preferredLanguage, roomNumber, secretary, uid, userCertificate, etc.;
Som du kan se förinställer accout bara några få nödvändiga och användbara attribut (det räcker definitivt för att slutföra inloggningsverifieringen), medan inetOrgPerson har många inbyggda attribut, såsom telefonnummer, mobilnummer, gatuadress, e-postadress, e-postadress, rumsnummer, avatar, chef, anställd nummer osv.
Därför rekommenderas det, när du konfigurerar LDAP, att ställa in objectClass-typen till accout om det bara är för att verifiera inloggning, och att sätta objectClass till inetOrgPerson om du vill skapa en stor och omfattande skattkista av medarbetarinformation
Här brukar jag använda 'inetOrgPerson', 'posixAccount', 'shadowAccount'.
De nödvändiga attributen för kontot är userid, medan de nödvändiga attributen för posixAccount är cn, gidNumber, homeDirectory, uid, uidNumber; Den obligatoriska attributet shadowAccount är uid, och de valfria attributen inkluderar shadowExpire, shadowInactive, shadowMax, shadowMin, userPassword, etc. Den viktigaste egenskapen är objectClass (det kan ses att top och andra objectClasses är ärvda relationer).
Attribut
Attribut liknar variabler i programmering och kan tilldelas. Många vanligt använda attribut deklareras i OpenLDAP (användare kan också definiera sina egna attribut). Vanliga attributbetydelser är följande:
- c: Country.
- CN: Common name, som syftar på namnet på ett objekt. Om det syftar på en person måste dess fullständiga namn användas.
- DC:Domänkomponent, ofta använd för att referera till en del av ett domännamn.
- givetNamn: syftar på en persons namn, inte ett efternamn.
- l: Syftar på ett ortnamn, såsom namnet på en stad eller annat geografiskt område.
- Mail: E-postadress.
- o:organizationName, vilket syftar på namnet på en organisation.
- ou:organizationalUnitName, som syftar på namnet på en organisatorisk enhet.
- SN: Efternamn, syftar på en persons efternamn.
- telephoneNumber: Telefonnumret, som bör innehålla koden för det land det ligger i.
Tips: objectClass är ett speciellt attribut som innehåller andra använda attribut samt sig självt.
För olika objectClasses finns det vanligtvis vissa nödvändiga egenskapsvärden och några valfria egenskapsvärden. Till exempel kan du använda objectClass of person för att representera en post för en användare i systemet, och användaren i systemet behöver vanligtvis viss information som namn, telefonnummer, lösenord, beskrivning osv. Som visas på bilden nedan, för person, ställ in användarens för- och efternamn via cn och sn, vilket är obligatoriskt, medan andra attribut är valfria.
Följande är en lista över några vanligt använda objectClass-krav som krävs.
- account:userid。
- organisation:o。
- PERSON: CN och SN.
- organisatoralPerson: Samma som person.
- organizationalRole:cn。
- organisationEnhet:ou。
- posixGroup:cn、gidNumber。
- posixAccount:cn、gidNumber、homeDirectory、uid、uidNumber。
(Slut)
|
Publicerad på 2020-06-23 22:34:54
|
|
|
|
Publicerad på 2023-05-19 11:23:09