HOWTO: dns mit ldap-zone-lookup

Alles rund um die Installation Eures Linuxsystems, sowie die Updatefunktionen des Systems und das Paketmanagement

Moderator: Moderatoren

Gesperrt
dialsc
Newbie
Newbie
Beiträge: 23
Registriert: 17. Apr 2004, 04:21

HOWTO: dns mit ldap-zone-lookup

Beitrag von dialsc » 12. Jun 2005, 02:27

hallo zusammen,

also, nachdem es nun laeuft, ich gefragt wurde wie und nun auch noch die zeit gefunden habe, hier nun also, wie man es anstellt.

vorne weg vielleicht noch, dass man bind in der version 9.1.0 oder neuer installiert haben muss.

weiter solltet ihr noch folgendes beruecksichtigen:
dieses howto wurde auf die hier beschriebene art unter suse linux 9.3 installiert. will heissen, es wird openLdap verwendet. in wie weit die hier aufgefuehrten pfadAngaben fuer ein anderes linuxSystem zutreffend sind, vermang ich nicht zu sagen, da ich noch nicht so lange bei linux dabei bin. ich denke aber, dass wenn ich davon sprechen, die slapd.conf zu editieren oder eine ldapSchemaDefinitionsDatei zu laden, dann wird dies wohl jeder hinbekommen, der schon ein ldap am laufen hat. dies ist im uebrigen natuerlich voraussetzung fuer dieses howto. also, ldap muss installiert, konfiguriert und lauffaehig sein!
weiter werden wir in diesem howto eine dnsZonen als master konfigurieren, die eine forwarding und eine reverse zone beinhaltet. in diesen werden wir die zonen mydomain.local und 100.168.192.in-addr.arpa konfigurieren. wir werden in diesem netzwerk einen server mit dem namen myserver haben und zwei weitere clients mit den namen client00 und client01. ausserdem wird es drei cnameEintraege geben. www, mail und ns werden alle samt aliasEintraege fuer myserver sein. zuguter letzt noch, wir gehen von einem in der /etc/openldap/slapd.conf wie folgt konfigurierten suffix aus " dc=mydomain,dc=local "!

wem das nun schon zu viel war, der sollte an dieser stelle nun stopen und sich zunaechst ausgiebig mit den themen bind und ldap beschaeftigen.

gut, nun aber zurueck zum thema. zunaechst muessen wir uns ein paar sachen herunter laden. eigentlich nur zwei, um genau zu sein.

bind patch http://www.venaas.no/ldap/bind-sdb/
dns zone ldap schema http://www.venaas.no/ldap/bind-sdb/dnszone-schema.txt

anschliessend den bind patchen, wie es in der INSTALL, welche im patchArchivFile enthalten ist, beschrieben wird.
ANMERKUNG: unter suse linux 9.3 ist dieser patch bereits in bind integriert und besitzer dieser distribution koennen sich das patchen sparen...

anschliesend den inhalt der ldapSchemaDatei als textDatei unter /etc/openldap/schema/dnszone.schema abspeichern. diese nun durch den ldapServer beim starten einlesen lassen. dies erreicht man, indem man in der datei /etc/openldap/slapd.conf folgende zeile hinzufuegt.

Code: Alles auswählen

...
include		/etc/openldap/schema/dnszone.schema
...
(man tut gut daran, dies an der stelle zu machen, wo all die anderen includeAnweisungen stehen)

bevor der ldapServer nun aber neu gestartet wird, muss auf jeden fall dafuer gesorgt werden, dass ebenfalls die datei cosine.schema geladen wird. dies ist notwendig, da die dnszone.schema auf dieser aufsetzt und wir spaeter attribute verwenden werden, welche in der cosine.schema definiert sind. dies ist das normale vorgehen. will heissen, es ist keine eigengestrickte loesung!
man sorge nun also dafuer, dass folgender eintrage in der
/etc/openldap/slapd.conf vorhanden ist und achte darauf, dass dieser vor dem include fuer die dnszone.schema definiert ist.

Code: Alles auswählen

...
include		/etc/openldap/schema/cosine.schema
...
weiter fuegen wir noch die folgenden anweisungen der /etc/openldap/slapd.conf hinzu und tun dies an der stellen, an der dort die indizes definiert sind.

Code: Alles auswählen

...
index                       zoneName                         eq
index                       relativeDomainName               eq
...
wenn in eurer /etc/openldap/slapd.conf die angaben fuer die indizes in einer zeile geschrieben sind, also in etwa so:

Code: Alles auswählen

...
index                      ... givenName, uidNumber, gidNumber, member, ...          eq
...
wobei ich gerade nicht wirklich weiss, ob dann auch wirklich ein komma zwischen den attributAngaben steht, dann fuegt ihr es halt dem dort angewandten schema entsprechend hinzu.

so, nun startet den ldapServer mal neu und schaut, dass er keine fehler berichtet. sollten fehler auftrette, dann kann ich nur empfehlen, dass ihr euch anschaut, welche logLevelDefinitionen es fuer die /etc/openldap/slapd.conf gibt, wendet entsprechend einen an und schaut euch dann an, was alles in die /var/log/messages geschrieben wird, waehrend ihr den ldapServer neu startet. das hilft sehr oft. folgender befehl ist dabei sehr hilfreich:

Code: Alles auswählen

tail -fn 100 /var/log/messages | grep slap
tail liest die testdatei aus. parameter f bestimmt, dass immer dann, wenn etwas der logDatei hinzugefuegt wird, dieses dann auch gleich in der shell, wo wir uns befinden, ausgegeben wird. parameter n mit der angabe 100 sagt tail, dass es die letzten 100 eintraege der logDatei ausgeben soll. schoen, haetten wir das auch...

gut, unser ldapServer laeuft nun also. fuegen wir nun mal etwas hinzu, was dann spaeter auch ausgelesen werden kann. wir werden unterhalbe des ldapSuffix einen ouEintrag " DNS " einfuegen, welcher weiter ouEintraege fuer zonenDaten wie etwa forwarding und reverse zones einer masterZone enthalten. dies sieht dann in etwa so aus:

Code: Alles auswählen

     |-dc=mydomain,dc=local
         |-ou=dns
             |-ou=zone.master
                  |-ou=forward
                  |    |-ou=mydomain.local
                  |    |
                  |    |    HIER KOMMEN DIE EINTRAEGE HIN
                  |
                  |-ou=reverse
                       |-ou=100.168.192.in-addr.arpa
                       |
                       |    HIER KOMMEN DIE EINTRAEGE HIN
kk, nun wissen wir, wo wir unsere dnsZonenDaten und -eintraege ablegen werden. schauen wir uns nun also an, was wir alles eintragen werden.
zunaechst schauen wir uns mal an, wie so eine zonenDefinition in einem textfile aussieht. hierzu nehmen wir diejenige genauer unter die lupe, welche uns die forwardingZone fuer unser netzwerk definiert.

Code: Alles auswählen

$TTL 2d
@		IN SOA		ns.mydomain.local.	root.mydomain.local. (
				                 2005051602	; serial
				                 3600		   ; refresh
				                 1800		   ; retry
				                 604800		 ; expiry
				                 86400 )		; minimum
mydomain.local.	IN MX		10 mail.mydomain.local.
mydomain.local.	IN NS		ns.mydomain.local.
myserver	       IN A	    192.168.100.1
client00	       IN A	    192.168.100.100
client01	       IN A	    192.168.100.101
mail		        IN CNAME	myserver
ns		          IN CNAME	myserver
www		         IN CNAME	myserver
k, dies laest sich in drei wesentliche teile zerlegen.
erstens der kopf, welcher sich vom anfang der datei bis inklusive der zeile "mydomain.local. IN NS ns.mydomain.local." erstreckt.
zweitens die definitionen fuer die hosts (IN A-eintraege) und drittens die definitionen der aliase (IN CNAME).

dies spiegelt dann auch wieder, wie wir die eintraege im ldap vornehmen muessen.
erstens einen fuer den kopf, in welchem die standardwerte fuer die zone definiert werden. dieser schaut in ldif-notation wie folgt aus:

Code: Alles auswählen

dn: relativeDomainName=@,ou=mydomain.local,ou=forward,ou=zone.master,ou=dns,dc=mydomain,dc=local
dNSClass: IN
dNSTTL: 3600
mXRecord: 10 mail.mydomain.local.
nSRecord: ns.mydomain.local.
objectClass: dNSZone
objectClass: top
relativeDomainName: @
sOARecord: ns.mydomain.local. root.mydomain.local. 2005051602 3600 1800 604800 86400
zoneName: mydomain.local
hier die definition des serverEintrags:

Code: Alles auswählen

dn: relativeDomainName=myserver,ou=mydomain.local,ou=forward,ou=zone.master,ou=dns,dc=mydomain,dc=local
aRecord: 192.168.100.1
dNSClass: IN
dNSTTL: 86400
objectClass: dNSZone
objectClass: top
relativeDomainName: myserver
zoneName: mydomain.local
hier die der clients:

Code: Alles auswählen

dn: relativeDomainName=client00,ou=mydomain.local,ou=forward,ou=zone.master,ou=dns,dc=mydomain,dc=local
aRecord: 192.168.100.100
dNSClass: IN
dNSTTL: 86400
objectClass: dNSZone
objectClass: top
relativeDomainName: client00
zoneName: mydomain.local

dn: relativeDomainName=client01,ou=mydomain.local,ou=forward,ou=zone.master,ou=dns,dc=mydomain,dc=local
aRecord: 192.168.100.101
dNSClass: IN
dNSTTL: 86400
objectClass: dNSZone
objectClass: top
relativeDomainName: client01
zoneName: mydomain.local
und zu guter letzt noch die aliasEintraege:

Code: Alles auswählen

dn: relativeDomainName=mail,ou=mydomain.local,ou=forward,ou=zone.master,ou=dns,dc=mydomain,dc=local
cNAMERecord: myserver.mydomain.local.
dNSClass: IN
dNSTTL: 86400
objectClass: dNSZone
objectClass: top
relativeDomainName: mail
zoneName: mydomain.local

dn: relativeDomainName=ns,ou=mydomain.local,ou=forward,ou=zone.master,ou=dns,dc=mydomain,dc=local
cNAMERecord: myserver.mydomain.local.
dNSClass: IN
dNSTTL: 86400
objectClass: dNSZone
objectClass: top
relativeDomainName: ns
zoneName: mydomain.local

dn: relativeDomainName=www,ou=mydomain.local,ou=forward,ou=zone.master,ou=dns,dc=mydomain,dc=local
cNAMERecord: myserver.mydomain.local.
dNSClass: IN
dNSTTL: 86400
objectClass: dNSZone
objectClass: top
relativeDomainName: www
zoneName: mydomain.local
nun mag sich vielleicht so manch einer fragen, wie er das denn nun in sein ldapVerzeichnis bekommt. hier nun also noch eine exkursion diesbezueglich.
wir speichern alle zuvor erwaehnten ldif-definitionen in einer textdatei. am anfang dieser textDatei, vor der ersten weiter oben genannten objektDefinition fuegen wir folgendes ein:

Code: Alles auswählen

dn: ou=dns,dc=mydomain,dc=local
objectClass: top
objectClass: organizationalUnit
ou: dns
description: Root Node meiner Bind9-Ldap-Konfiguration

dn: ou=zone.master,ou=dns,dc=mydomain,dc=local
objectClass: top
objectClass: organizationalUnit
ou: zone.master
description: Root Node meiner Master-Zonen-Konfiguration

dn: ou=forward,ou=zone.master,ou=dns,dc=mydomain,dc=local
objectClass: top
objectClass: organizationalUnit
ou: forward
description: Root Node meiner Forward-Master-Zonen-Konfiguration

dn: ou=mydomain.local,ou=forward,ou=zone.master,ou=dns,dc=mydomain,dc=local
objectClass: top
objectClass: organizationalUnit
ou: mydomain.local
description: Forward-Definition fuer mydomain.local

dn: ou=reverse,ou=zone.master,ou=dns,dc=mydomain,dc=local
objectClass: top
objectClass: organizationalUnit
ou: reverse
description: Root Node meiner Reverse-Master-Zonen-Konfiguration

dn: ou=100.168.192.in-addr.arpa,ou=reverse,ou=zone.master,ou=dns,dc=mydomain,dc=local
objectClass: top
objectClass: organizationalUnit
ou: 100.168.192.in-addr.arpa
description: Reverse-Definition fuer 192.168.100.0
nun navigieren wir in unserer shell in das verzeichnis, wo wir diese textDatei abgelegt haben. per konvention geben wir ihr in ihrem namen noch die dateiEndung .dif.
angenommen, wir haben der datei den namen "dnsinput.ldif" gegeben, fuehren wir nun diesen befehl aus:

Code: Alles auswählen

myserver:/pfad/zu/meiner # slapadd -c -f ./dnsinput.ldif -h localhost -v -x -D "cn=admin,dc=mydomain,dc=local" -W
wobei gilt:

-c besagt, dass bei einem fehler nicht abgebrochen, sondern weiter gemacht werden soll. ACHTUNG: unbedingt kontrollieren, was eingetragen wurde und was nicht. aber das macht man ja eh, gell... ;-)
-f klar, oder...
-v verbose
-x simpleauthentication mechanism
-D "..." hier muesst ihr den adminAccount angeben, denn ihr unter rootdn in der /etc/openldap/slapd.conf angegeben habe, oder ihr seit schon weiter hinsichtlich acl und/oder aci und verwendet ein userAccount mit den entsprechenden rechten. ach, was laber ich, das wisst ihr ja eh, oder...
-W besagt, dass nach dem absetzen des kommandos noch das passwort fuer die verbindung zum verzeichnisdienst abgefragt werden soll. man kann an stelle dessen auch " -w secret " verwenden, wobei secret dann natuerlich das passwort fuer den verwendeten binddn sein muss.

nachdem diese eintraege nun also dem ldapVerzeichnis hinzugefuegt wurden, sieht dieses nun in etwa so aus:

Code: Alles auswählen

     |-dc=mydomain,dc=local
         |-ou=dns
             |-ou=zone.master
                  |-ou=forward
                  |    |-ou=mydomain.local
                  |        |-relativeDomainName=@
                  |        |-relativeDomainName=client00
                  |        |-relativeDomainName=client01
                  |        |-relativeDomainName=mail
                  |        |-relativeDomainName=myserver
                  |        |-relativeDomainName=ns
                  |        |-relativeDomainName=www
                  |
                  |-ou=reverse
                       |-ou=100.168.192.in-addr.arpa
nun wollen wir ja aber nicht nur eine forward-lookup-zone einrichten, sondern auch eine reverse. ich kuerz jetzt an dieser stelle ein klein wenig ab und praesentiere gleich die gesamte lidfDatei. wer ein klein wenig genauer hin schaut, der wird die unterschiede recht schnell sehen und sich ableiten koennen, wie man einen reverseLookupEintrag erstellt.
hier nun also die ldif-datei:

Code: Alles auswählen

dn: relativeDomainName=@,ou=100.168.192.in-addr.arpa,ou=reverse,ou=zone.master,ou=dns,dc=mydomain,dc=local
dNSClass: IN
dNSTTL: 3600
mXRecord: 10 mail.mydomain.local.
nSRecord: ns.mydomain.local.
objectClass: dNSZone
objectClass: top
relativeDomainName: @
sOARecord: ns.mydomain.local. root.mydomain.local. 2005051602 3600 1800 604800 86400
zoneName: 100.168.192.in-addr.arpa

dn: relativeDomainName=1,ou=100.168.192.in-addr.arpa,ou=reverse,ou=zone.master,ou=dns,dc=mydomain,dc=local
dNSClass: IN
dNSTTL: 86400
objectClass: dNSZone
objectClass: top
pTRRecord: myserver.mydomain.local.
relativeDomainName: 1
zoneName: 100.168.192.in-addr.arpa

dn: relativeDomainName=100,ou=100.168.192.in-addr.arpa,ou=reverse,ou=zone.master,ou=dns,dc=mydomain,dc=local
dNSClass: IN
dNSTTL: 86400
objectClass: dNSZone
objectClass: top
pTRRecord: client00.mydomain.local.
relativeDomainName: 100
zoneName: 100.168.192.in-addr.arpa

dn: relativeDomainName=101,ou=100.168.192.in-addr.arpa,ou=reverse,ou=zone.master,ou=dns,dc=mydomain,dc=local
dNSClass: IN
dNSTTL: 86400
objectClass: dNSZone
objectClass: top
pTRRecord: client01.mydomain.local.
relativeDomainName: 101
zoneName: 100.168.192.in-addr.arpa
ist diese ebenfalls in das ldapVerzeichnis eingelesen worden, so sieht jenes nun wie folgt aus:

Code: Alles auswählen

     |-dc=mydomain,dc=local
         |-ou=dns
             |-ou=zone.master
                  |-ou=forward
                  |    |-ou=mydomain.local
                  |        |-relativeDomainName=@
                  |        |-relativeDomainName=client00
                  |        |-relativeDomainName=client01
                  |        |-relativeDomainName=mail
                  |        |-relativeDomainName=myserver
                  |        |-relativeDomainName=ns
                  |        |-relativeDomainName=www
                  |
                  |-ou=reverse
                       |-ou=100.168.192.in-addr.arpa
                           |-relativeDomainName=@
                           |-relativeDomainName=1
                           |-relativeDomainName=100
                           |-relativeDomainName=101
schauen wir uns nun an, wie wir unserem bind verklickern koennen, dass er diese konfiguration auslesen und anwenden soll.
hierzu nehmen wir uns die /etc/named.conf zur hand und editieren sie unseren anforderungen entsprechend.
hierfuer fuegen wir folgende zonenDefinitionen hinzu:

Code: Alles auswählen

zone "100.168.192.in-addr.arpa" in {
        type master;
        database "ldap ldap://xxx.xxx.xxx.xxx/ou=100.168.192.in-addr.arpa,ou=reverse,ou=zone.master,ou=dns,dc=mydomain,dc=local 172800";
}

zone "mydomain.local" in {
        type master;
        database "ldap ldap://xxx.xxx.xxx.xxx/ou=mydomain.local,ou=forward,ou=zone.master,ou=dns,dc=mydomain,dc=local 172800";
}
(ersetzt xxx.xxx.xxx.xxx mit der ipAdresse, auf welcher euer ldapServer lauscht. z.b. 127.0.0.1 oder 192.168.100.1. verwendet keine dnsNamen, diese kann bind beim starten noch nicht aufloesen. dem aufmerksamen leser wird nicht entgangen sein, dass dieses mir zum verhaengnis wurde... ;-) die zahl 172800 am ende definiert die standardTTL, welche bind anwenden wird, sollte keine im verzeichnisdienst konfiguriert sein. jede der beiden zonenDefinitionen enthaelt eine zeile, welche angibt, wie und wo auf den verzeichnisdienst zugegriffen werden soll. diese definition " database ... " ist jeweils in EINER zeile zu notieren. den umbruch macht hier nur euer browser!)

also, wenn wir bind nun neu starten, dann wird er uns die zonenDefinitionen, welche wir im ldapVerzeichnis definierten, auslesen und uebernehmen. zum testen sollte nun also der namensserver in der konfiguration der ipEinstellungen der lokalen maschine auf den server gesetzt werden, auf welchem der ldapKonfigurierte bind laeuft. wenn das die gleichen maschine ist, wie die, auf der man arbeitet, dann einfach 127.0.0.1 als namensserver eintragen. anschliessend sollte eine nslookup in etwa folgendes ergebnis liefern:

Code: Alles auswählen

myserver:~ # nslookup www.mydomain.local
Server:      127.0.0.1
Address:     127.0.0.1#53

www.mydomain.local canonical name = myserver.mydomain.local
Name:     myserver.mydomain.local
Address:  192.168.100.1
bevor wir nun aber in jubel ausbrechen, weil unser bind das macht, was wir wollen, das er macht, schauen wir uns noch ein weiteres, sehr wichtiges thema an.
in unserer aktuellen konfiguration verbindet sich der bind naemlich als anonymer benutzer. wer schon mal mit acl oder aci gearbeitet hat, weiss was nun kommt. fuer alle anderen schnell ne kleine erklaerung. in openldap ist es moeglich, mittels sogenannter acl- und/oder aciEintraegen zugriffsBerechtigungen fuer einzelne eintraege im verzeichnis oder fuer ganze teilBaeume oder das gesamte verzeichnis zusammen zu erstellen, wobei auch kombinationen zulaessig sind. hierbei wird es natuerlich interessant, wenn man angeben kann, dass der benutzer XY zugriff auf bereiche hat, bzw. dort eintraege erstellen, editieren und loeschen kann, was andere benutzer nicht koennen. ein adminAccount sozusagen. oder man macht es an der mitgliedschaft einer bestimmten gruppe im ldapVerzeichnis fest. die moeglichkeiten sind sehr umfangreich und man kann sich durch aus in der endlosigkeit von detailAclDefinitionen verlieren... ;-)
well, um dies umsetzen zu koenne, sollten wir wissen, wann bind sich anmeldet. wir koennen bind hierzu sagen, dass es bestimmte zugangsdaten beim verbinden mit dem verzeichnisdienst verwenden soll. bevor wir das nun in der /etc/named.conf eintragen, erstellen wir uns zunaechst einen solchen benutzer in unserem ldapVerzeichnis, der ausschliesslich dazu verwendet werden wird, bind das anmelden am verzeichnisdienst und den zugriff auf die zonenDefinitionen zu ermoeglichen.
hierzu erstellen wir ein simpleSecurityObject und speichern es unter ou=dns,dc=mydomain,dc=local ab, wobei es den benutzernamen bind9.ldapbindaccount bekommen wird.
zuvor muessen wir uns aber noch die verschluesselte version eines passwortes erstellen. hierzu geben wir in unserer shell folgendes kommando ein (wobei changeit durch ein von euch gewahltes passwort ersetzt werden sollte!):

Code: Alles auswählen

myserver:~ # ldappasswd -h {MD5} -s changeit
{MD5}uRzRpUeBeQvqorr3QfpniQ==
(md5 ist hierbei nicht nur mein favorit, sondern sehr verbreitet. es bietet die moeglichkeit, auch laengere passworter (unix traditionel 8 zeichen) zu verwenden und bietet durch den verwendetet algorithmus ausreichend schutz. fuer spaeter projekte hier ein kleiner tip: openldap verwendet base64-encoded md5 (ich meine, es heisst so))

dieses passwort benutzen wir nun also um eine definition unseres bindBenutzerKontos in ldif-notation zu erstellen:

Code: Alles auswählen

dn: uid=bind9.ldapbindaccount,ou=dns,dc=mydomain,dc=local
uid: bind9.ldapbindaccount
userPassword: {MD5}uRzRpUeBeQvqorr3QfpniQ==
objectClass: top
objectClass: account
objectClass: simpleSecurityObject
diese nun in unseren verzeichnisdienst eingefuegt, sieht jener nun wie folgt aus:

Code: Alles auswählen

     |-dc=mydomain,dc=local
        |-ou=dns
        |    |-ou=zone.master
        |         |-ou=forward
        |         |    |-ou=mydomain.local
        |         |        |-relativeDomainName=@
        |         |        |-relativeDomainName=client00
        |         |        |-relativeDomainName=client01
        |         |        |-relativeDomainName=mail
        |         |        |-relativeDomainName=myserver
        |         |        |-relativeDomainName=ns
        |         |        |-relativeDomainName=www
        |         |
        |         |-ou=reverse
        |              |-ou=100.168.192.in-addr.arpa
        |                  |-relativeDomainName=@
        |                  |-relativeDomainName=1
        |                  |-relativeDomainName=100
        |                  |-relativeDomainName=101
        |-uid=bind9.ldapbindaccount
und nun packen wir das ganz noch in unsere /etc/named.conf, welche darauf hin folgende zonenDefinitionen verwendet:

Code: Alles auswählen

zone "100.168.192.in-addr.arpa" in {
        type master;
        database "ldap ldap://xxx.xxx.xxx.xxx/ou=100.168.192.in-addr.arpa,ou=reverse,ou=zone.master,ou=dns,dc=mydomain,dc=local????!bindname=uid=bind9.ldapbindaccount%2cou=dns%2cdc=mydomain%2cdc=local,!x-bindpw=changeit 172800";
}

zone "mydomain.local" in {
        type master;
        database "ldap ldap://xxx.xxx.xxx.xxx/ou=mydomain.local,ou=forward,ou=zone.master,ou=dns,dc=mydomain,dc=local????!bindname=uid=bind9.ldapbindaccount%2cou=dns%2cdc=mydomain%2cdc=local,!x-bindpw=changeit 172800";
}
(die ldapDefinitionen hinter database sind in EINER zeiler zu notieren!)

und schon verwendet bind die hier angegebenen zugangsdaten. die verwendung von %2c an stell von kommas und die vielen fragezeichen sind im uebrigen keine tipFehler. das muss so sein. %2c deswegen, da kommas hier als paramerterTrennzeichen fuer die gesammte ldapSpezifische konfiguration verwendet werden.
gut, machen wir nun noch aus " !x-bindpw=changeit " ein " !x-bindpw=changeit,x-tls ", so connected bind auch noch unter der verwendung einer gesicherten verbindung.

jetzt sollte eigentlich soweit alles tun. testet den nslookup wie weiter oben geschildert noch einmal. und schaut in die logFiles, wenn etwas nicht geht.
als letztes bleibt noch zu erwaehnen, wie bind eigentlich nach daten im ldapVerzeichnis sucht. es verwendet hierzu die folgenden search filter:

Code: Alles auswählen

zum auslesen der zonenDaten beim startup:
    filter="(&(zoneName=100.168.192.in-addr.arpa)(relativeDomainName=@))"
    filter="(&(zoneName=mydomain.local)(relativeDomainName=@))"

beim aufloesen eines hostnamens (www.mydomain.local):
    filter="(&(zoneName=mydomain.local)(relativeDomainName=www))"

beim aufloesen eines reverseLookups (192.168.100.100):
    filter="(&(zoneName=100.168.192.in-addr.arpa)(relativeDomainName=100))"
eigentlich sind es einige abfragen mehr, welche unterschiedliche werte fuer das attribut relativeDomainName definieren. im wesentlichen reicht es aber, die hier aufgefuehrten zu wissen, um sich gedanken machen zu koennen, wie flexibel mit diesem werkzeug dnsAufgaben gemanaged werden koennen.

so, nun haben wir so ziemlich alles besprochen.

ich hoffe es wird dem ein oder anderen helfen und ihr verzeiht mir die fehler und zusammenhangslosen saetze... ;-)

viel spass beim basteln und einen schoenen tag noch.

dialsc
Zuletzt geändert von dialsc am 13. Jun 2005, 16:25, insgesamt 4-mal geändert.

Werbung:
Gesperrt

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste