none
Hinzufügen eines Computers zur Domäne erfolgt nicht mit richtiger DNS-Syntax RRS feed

  • Allgemeine Diskussion

  • Hallo zusammen,

    wir sind im Moment dabei, unsere Windows Clients von XP X86 auf Windows 7 X64 umzustellen. Bisher hatten wir beim automatischen Deployment "netdom" zum Hinzufügen der Computerkontos ins ADS genutzt. Es funktionierte auch ohne Probleme.

    Nun testete ich sowohl das neue Netdom, als auch das "add-computer" cmdlet der Powershell und musste feststellen, dass die DNS-Syntax im AD für das Computerkonto nicht richtig übernommen wurde. Dementsprechend kann ich Domänenbenutzer auch auf der W7-Station nicht anmelden.

    Die Besonderheit bei uns ist, das wir eine strukturiertes DNS eingerichtet haben, das über die Jahre und über verschiedene heterogene Systeme so gewachsen ist (DHCP und DNS über Linux Server, DNS auf DC nur für AD-relevanten Anteil). Darin sind die Clients für die Abteilungen nochmals mit dem Abteilungkürzel erfasst, d.h. ein Client für unsere Domäne "Domäne.de" hat einen DNS-Namen  "Computer.Abt.Domäne.de" und nicht einfach nur "Computer.Domäne.de", so wie es im AD sonst üblich ist.

    Deshalb haben wir auch vor dem Domänenbeitritt den Primären DNS Suffix auf die entprechende Abteilung eingerichtet "Abt.Domäne.de" und das automatische Ändern beim Domänenbeitritt entfernt. Dann erst wurde der Computer mit "netdom" der Domäne zugeordnet.

    Das Computerkonto hatte dort dann auch richtig den DNS Namen "Computer.Abt.Domäne.de" und alles funktionierte. Das war bei Windows XP.

    Bei Windows 7 hängt er mir einfach nur den Domänennamen an, ohne sich darum zu kümmern, ob ich einen anderen Primären Domänen Suffix benötige oder nicht, also steht im Computerkonto unter DNS Namen nur noch "Computer.Domäne.de". Da der Client aber immer noch "Computer.Abt.Domäne.de" heißt, lässt sich kein Domänenbenutzer anmelden. Fehlermeldung:

    "The security database on the server does not have a computer for this workstation trust relationship"

    Egal was ich probiert habe, netdom oder Powershell "add-computer", beides liefert dasselbe Ergebnis. Optionen für die Mitgabe dieses Primary DNS Suffix hatte ich für beide nicht gefunden.

    Erst wenn ich den Computer über die GUI in den Systemeigenschaften des Computers neu beim AD anmelde, setzt er mir den Eintrag wieder richtig. Dann heisst der DNS-Eintrag im Computerkonto des AD auch wieder "Computer.Abt.Domäne.de" und alles funktioniert wieder.

    Selbst das Einrichten einer Gruppenrichtlinie local oder auch übers AD für die betreffende OU zum Setzen eine "Primären DNS Suffixes" bewirkte nichts.

    Da ich aber unsere Clients nicht wieder manuell anmelden möchte und wir unsere DNS-Struktur nicht so einfach umstellen können, würde ich gern die bisherige Verfahrenweise weiter nutzen wollen.

    Ich würde mich über Hilfe dazu sehr freuen. Viele Grüße 

    Mittwoch, 13. Oktober 2010 10:08

Alle Antworten

  • Moin,

    ich würde nicht ausschließen, dass die Kommandozeilentools für diese Besonderheit nicht die nötige Logik mitbringen. Du könntest versuchen, einen Supportcase dazu zu eröffnen.

    Gruß, Nils

     


    Nils Kaczenski
    MVP Directory Services
    Hannover, Germany
    Donnerstag, 14. Oktober 2010 12:01
  • Hallo

    ist das Problem noch aktuell? Konntest du inzwischen eine Lösung/Workaround dazu finden?

    Gruß
    Andrei

    Donnerstag, 21. Oktober 2010 08:44
    Moderator
  • Hallo

    wir haben dasselbe Problem hier - das Problem bleibt aktuell bis das Scriptlet überarbeitet ist.

    Zum reproduzieren:

    Domäne: abc.de

    Rechnername: xyz

    - Vor dem Domainjoin sicherstellen, daß kein gleichnamiges Computerobjekt im AD ist

    - Vor dem Domainjoin via sysdm.cpl beim Computernamen das Primäre Suffix ändern zu 'bla.abc.de', sowie das Häkchen entfernen bei 'Suffix bei Domänenmitgliedschaft ändern'. Ggf. neustarten.

    - Mit Powershell add-computer ausführen

    - Überprüfen, daß tatsächlich beim resultierenden Computerobjekt das Attribut 'dNSHostName' nicht dem lokalen vollen Computer-DNSNamen entspricht.

    Wir werden hier mal untersuchen, ob man nicht z.B. mit ADMOD (oder einem fähigen Skript) vom anzumeldenden Rechner aus im AD das Attribut direkt nachbessern kann - aber selbst wenn das geht, ist ätzend, daß man dann ein zweites mal dazu eine Anmeldung durchführen müsste.

    Dienstag, 30. November 2010 11:56
  • Folgendermassen haben wir das Problem "bereinigt":

    Wir aktualisieren direkt nach Add-Computer mit ADMOD das entstandene Computerobjekt.

    1.) Lesen des aktuellen lokalen Spezial-suffixes aus
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters
    NV Domain

    2.) Korrektur des dNSHostName Attributes im Computerobjekt
    Änderung von xyz.abc.de auf xyz.bla.abc.de

    3.) Korrektur des servicePrincipalName Attributes im Computerobjekt
    Änderung von
    HOST/XYZ
    HOST/.bla.abc.de
    RestrictedKrbHost/XYZ
    RestrictedKrbHost/.bla.abc.de
    auf
    HOST/XYZ
    HOST/XYZ.bla.abc.de
    RestrictedKrbHost/XYZ
    RestrictedKrbHost/XYZ.bla.abc.de

     

    2 und 3 geht im Prinzip so:
    set adsuffix=bla.abc.de
    set adtempcmd1=dNSHostName::%adsuffix%
    set adtempcmd2="servicePrincipalName:+-:HOST/%COMPUTERNAME%;HOST/%COMPUTERNAME%.%adsuffix%;RestrictedKrbHost/%COMPUTERNAME%;RestrictedKrbHost/%COMPUTERNAME%.%adsuffix%"
    admod.exe -u %ouadmin% -up * -b "LDAPPFADZUCOMPUTEROBJEKT" %adtempcmd1% %adtempcmd2%

     

    Natürlich bleibt das Problem ein Problem und das Add-Computer Scriptlet benötigt einen Bugfix.

    Liebe Moderatoren, könnt Ihr sowas einleiten?

    P.S. mein gott, was für ein schrecklicher editor ;)

     

    Dienstag, 30. November 2010 20:04