Thalmayr

Hallo Experten, kennt jemand eine Möglichkeit, wie ich für das Kerberos-TGT den Encryption-Type DES .... erzwingen kann? Bei W2K ging das indem ich beim Benutzer den Haken "DES für Passwort ..." gesetzt habe. Bei W2K3 hilft das allerdings nicht. Den Encryption-Type eines ausgestellten TGTs kann man mit dem Tool kerbtray ansehen. Hintergrund: Die Sun JVM kann keine TGTs mit RC4 entschlüsseln - dies ist aber der Standard Encryption-Type für TGTs welche vom AD-KDC ausgestellt werden. Vielen Dank für etwaige Hinweise. Gruß, Bernhard

Habe die Lösung gefunden (hatte wohl anfangs Tomaten auf dem Augen bei der Analyse der Netzwerkdaten :mad: ). :D Also 1. Man kann entweder A oder PTR Records pro nsupdate Verbindung aktualisieren . - das liegt daran, dass pro Verbindung nur einmal das Keyword "zone" verwendet werden kann 2. nsupdate bestimmt entgegen der manpage die zu ändernde Zone nicht selbst (zu mindest bei mir nicht) - also Keyword "zone" verwenden 3. Beim Eintrag von PTR records muss man sich natürlich an die richtige Syntax halten (wie wenn man die db-files manuell pflegt). Beispiele: Forward-Eintrag server 192.168.1.7 [optional - spart aber eine SOA query] zone enterprise.com. prereq nxdomain mysql6.enterprise.com. update add mysql6.enterprise.com 0 A 192.168.1.25 send Reverse-Eintrag server 192.168.1.7 zone 1.168.192.in-addr.arpa. prereq nxdomain 25.1.168.192.in-addr.arpa. update add 25.1.168.192.in-addr.arpa. 0 PTR mysql6.enterprise.com send Interessant ist, dass die MS clients nur überprüfen ob ein CNAME Eintrag (prereq nxrrset mysql6.enterprise.com. CNAME resp. prereq nxrrset 25.1.168.192.in-addr.arpa. CNAME) vorhanden ist und nicht ein "any" Eintrag (prereq nxdomain). Ob das so ganz ok ist ? HTH, Bernhard

Vielen Dank, ich dachte mir, wenn der Client einen leeren Suffix schickt, dann könnte der DHCP-Server ja aus der eigenen Konfiguration (DNS-Domainname für diesen Bereich) wissen, welchen FQDN er zu registrieren hat. Im Falle der oben genannten Einstellung sollte ja der DHCP-Server die Einträge im DNS-Server tätigen, dann wäre es ja egal, ob die Registrierung welche der Client durchführt fehlschlägt oder nicht. Wäre das auch nicht der Fall, wenn man die client-seitige Registrierung per Registry total abschaltet? -Bernhard

.. und es würde auch nicht helfen, wenn man für diesen DHCP-Bereich die Option "DNS-Domänenname" setzen würde? Dann hätte ja der DHCP-Server eigentlich alle notwendigen Informationen (IP und FQDN)- oder liege ich hier falsch? Danke für die Erhellung. -Bernhard

Tritt das Gewünschte ein, wenn man bei der DHCP Konfiguration "DNS immer aktualisieren" und "Aktualisieren für DNS-Clients, die dynamisches Aktualisieren nicht unterstützen, aktivieren" auswählt. Laut MS webcast sollte dann der DHCP Server sowohl A als auch PTR Records im DNS Server eintragen. -Bernhard

Hallo Experten, ich hoffe jemand kann mir bei folgenden Problem weiterhelfen. Ich möchte gerne per nsupdate A und PTR Einträge im W2K DNS server erzeugen. Leider bekomme ich immer ein "refused" zurück. bash-3.00$ /usr/sbin/nsupdate > prereq nxdomain mysql6.enteprise.com > prereq nxdomain 192.168.1.25 > update add mysql6.enteprise.com 86400 A 192.168.1.25 > update add 192.168.1.25 86400 PTR mysql6.enteprise.com > send update failed: REFUSED Alle möglichen Fehlerquellen, welche ich in der Knowlegebase und per Google gefunden habe treffen nicht zu. z.B. DNS funktioniert bash-3.00$ /usr/sbin/nslookup > set query=SOA > enterprise.com Server: 192.168.1.7 Address: 192.168.1.7#53 enterprise.com origin = uhura.blackhole.enterprise.com mail addr = administrator.blackhole.enterprise.com serial = 59 refresh = 900 retry = 600 expire = 86400 minimum = 3600 Die Zone ist auf "primary" gesetzt und "dynamic updates" sind erlaubt C:\>dnscmd /ZoneInfo enterprise.com Zone query result: Zone info: ptr = 00075358 zone name = enterprise.com zone type = 1 update = 1 DS intergrated = 0 data file = enterprise.com.dns ... respektive reverse-lookup-zone C:\>dnscmd /ZoneInfo "1.168.192.in-addr.arpa" Zone query result: Zone info: ptr = 00075378 zone name = 1.168.192.in-addr.arpa zone type = 1 update = 1 DS intergrated = 0 ... Im Netzwerktrace sind alles ok aus, Zonentransfers sind unterbunden. Weder das dns log noch der event viewer zeigt mir den Grund für die Verweigerung an. Hat jemand noch eine Idee? Bin für jeden Tipp dankbar. -Bernhard