Domänen-Beitritt plötzlich nicht mehr möglich

[MathiasRR 10]

Moin moin,

 

aaaalso...... Die Shared Folders sind unter VMWare deaktiviert, sollten also kein Problem machen, richtig?

 

Bei dem VMWAre-Guest handelte(!) es sich um eine geclonte Maschine, die ich aber inzwischen auch schon komplett neu wieder installiert habe.

Daher sollte es mit der SID keine Probleme geben.

 

Ich habe eben mal einen alten 600MHz Rechner aus dem Keller geholt der die Domäne noch nie gesehen hatte (XPPro, SP2) und habe versucht diese Hardware in die Domäne zu bekommen:

Gleicher Fehler wie bei der VMWare-Maschine..... :cry:

 

Übrigens: Ich hatte ja geschrieben dass sich die Rechner schon im AD anlegen, nur dann mit einem roten X dort drinne stehen.

Wenn ich den Maschinen-Account dann händisch aktiviere, kann ich den Client in die Domäne bekommen indem auch bei der Abfrage nach Username und Passwort (beim hinzufügen zur Domäne) einfach die Felder leer lasse und OK drücke.

Allerdings hat der Client dann Probleme nach einem Reboot sich korrekt anzumelden, er bleibt denn bei Computereinstellungen oder Benutzereinstellungen werden geladen, hängen.

 

 

Danke euch für die Hilfe bisher!!!!!! Hat denn noch wer ne andere Idee?

 

 

Viele Grüße

Mathias :)

[gysinma1 13]

Hallo

 

Ich kann gerne auch noch meinen Senf dazu geben ;-)

 

- Die Windowsfirewall ist ausgeschaltet ?

- Kannst Du uns noch was zu dem DC verraten ? Ist der Neuinstalliert älter genaues Betriebssystem ?

- Gibt es Netbios/WINS Server im Netz

- Wie sieht die Authentizierung der Domain aus NTLM etc. Ich hat da mal was verstellt und kriegte keine clients mehr in die Domain

- Du sagst dass der rsop Prozess (wenn die GPOs applied tierisch langsam sind).

- Wurden Änderungen in den GPOs gemacht ?

- WSUS würde ich fast ausschliessen, sonst stoppe den automatic update service und disable ihn nach reboot wird das wohl gleich sein

 

 

Da es bei einer physikalischen Maschine auftritt wundert mich nicht. Ich tippe jedoch auf ein Problem mit dem Domaincontroller und nicht mit dem client. Ich würde auf dem DC alle default gruppenrichtlinien zurücksetzen (s. Gruppenrichtlinien - Übersicht, FAQ und Tutorials). Vorher kannst Du auch mit dem tool rsop.msc nachprüfen welche Policies applied werden.

 

Gruss

Matthais

[olc 18]

Hi,

 

grundsätzlich gute Punkte von gysinma1, ich wäre jedoch nicht so leichtfertig alle Policies zurückzusetzen. ;)

Außerdem wurden einige der Fragen schon beantwortet.

 

Da wir nun erst einmal einige grundsätzlichen Dinge abgeklopft haben, kann man weiter machen. Vorher ist das Problem meist nur schwer möglich einzugrenzen (ob Client oder DC Problem).

 

Ich könnte mir auch vorstellen, daß es ein Problem mit den NTLM Einstellungen gibt. Prüf doch einmal die folgende Policy: "LAN Manager Authentication Level: Send NTLMv2 response only\refuse LM & NTLM" (siehe Microsoft Corporation)

Was ist dort eingestellt?

 

Bitte schaue auf einem Client, der Probleme beim Joinen hat, unterhalb von %SYSTEMROOT%\Debug nach der Datei "Netsetup.log". Bitte stell die einmal zur Verfügung. Dort kann man sehen, was während des Joins passiert - vielleicht ist etwas zu sehen.

 

Der Hinweis von blub bezüglich des Netzwerktrace ist auch gut, vielleicht kannst Du den Vorgang einmal tracen.

 

Bitte mach auch einmal einen LDIFDE Export des Client-Objekts, nachdem es mit einem roten X markiert ist, also deaktiviert (oder schau mittels ADSIEdit bzw. LDP) - hat der Client eine SID zugewiesen bekommen?

 

Ich gehe davon aus, daß der Benutzer, mit dem Du die Clients in die Domäne holst, Domain-Admin ist? In wie vielen Gruppen ist der Benutzer Mitglied? Geht es unter Umständen mit einem anderen Benutzer?

 

Als nächsten Punkt solltest Du folgenden KB-Artikel prüfen: You receive an error message when you join a domain with Windows XP

 

Wenn Du mit allem durch bist, melde Dich wieder. ;)

 

Viele Grüße

olc

[blub 115]

man könnte noch das KerberosLogging am Client und DC aktivieren, falls es tatsächlich ein NTLM/Kerberos Problem ist.

s.KB 262177

(wobei man etwas aufpassen muss, da damit auch kerberosEvents (Errors) geworfen werden, die überhaupt kein Problem darstellen)

 

Enabling Kerberos Event Logging on a Specific Computer

Start Registry Editor.

Add the following registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

 

 

Registry Value: LogLevel

Value Type: REG_DWORD

Value Data: 0x1

 

If the Parameters subkey does not exist, create it.

 

Note Remove this registry value when it is no longer needed so that performance is not degraded on the computer. Also, you can remove this registry value to disable Kerberos event logging on a specific computer.

Quit Registry Editor. The setting will become effective immediately on Windows Vista, on Windows Server 2003, and on Windows XP. For Windows 2000, you must restart the computer.

You can find any Kerberos-related events in the system log.

 

Also wenn ma's jetzt nicht rauskriegen, dann weiss ich auch nicht mehr :)

 

 

cu

blub

[NorbertFe 2.110]

Hi,

 

grundsätzlich gute Punkte von gysinma1, ich wäre jedoch nicht so leichtfertig alle Policies zurückzusetzen. ;)

 

Warum? Es geht um die beiden Default Policies. ;) ERstens kann man die ja schnell kopieren und danach erst zurücksetzen und zweitens sollte dort eh eine sehr überschaubare Anzahl von Einstellungen drin vorgenommen sein. ;)

 

Bye

Norbert

[olc 18]

...ja, im Idealfall schon. Da hast Du / habt Ihr Recht. ;)

Wenn man dann aber konsequent sein will, sollte man auch gleich noch die Security DB zurücksetzen. :)

 

Gruß olc

[Sam Fisher 10]

Hallo !

Bitte verzeiht wenn ich hier einfach so meinen Senf dazugebe, aber Kerberos ist doch ein Zeitkritisches Protokoll. Kann es sein, dass der Fehler schlicht weg eine zu große Differenz der Zeit an DC und am Client ist?

 

Grüße

Sam

[olc 18]

Hi Sam,

 

wieso verzeihen - ist doch ein guter Einwand. :)

 

Ich würde das jedoch eigentlich ausschließen, da

a) laut TO keine Events geloggt werden

b) auch Clients nicht zurück in die Domäne geholt werden können, die gerade noch drin waren - die sollten im Normalfall synchron mit dem PDCe sein

 

Aber checken kann man es ja trotzdem mal (neben den anderen Themen). :)

 

Viele Grüße

olc

 

–

 

...habe das gerade noch einmal getestet - die Zeit wird automatisch nach Abgleich der Credentials bzw. bei größeren Differenzen beim Neustart beim Domänenbeitritt auf die Zeit des DCs gesetzt, mit dem man gerade verbunden ist (in diesem konkreten Fall ist ja nur einer da). W32TM machts möglich.

 

Wußte ich bisher auch nicht. Coole Sache. ;)

 

Daran sollte es also nicht liegen - aber Du kannst es ja trotz alledem noch einmal prüfen.

 

Sind ja erst einmal ein paar Schritt durchzuführen, bis wir hier weitermachen können. ;)

 

Viele Grüße

olc

[Jim di Griz 13]

"Beim Versuch der Domäne xxxxx beizutreten, trat der folgende Fehler auf:

Der angegebene Server kann den angeforderten Vorgang nicht ausführen.

 

Welche eventid hat dieser Fehler im Eventlog des Servers oder clients und welcher errorcode wird hierzu ausgegeben?

[olc 18]

... auch diese Frage wurde schon geschätzte 12x beantwortet. ;)

 

Gruß olc

[MathiasRR 10]

Moin moin,

 

sorry, hat nen bissel gedauert. Aber der Job und dann noch nen Gebutstag in der Familie.....

 

 

Hallo

- Die Windowsfirewall ist ausgeschaltet ?

 

Jepp, ist aus, auf dem CLient als auch auf dem Server

 

- Kannst Du uns noch was zu dem DC verraten ? Ist der Neuinstalliert älter genaues Betriebssystem ?

 

2003 Enterprise. Installiert wurde der so vor 2 Monaten.... Was möchtest du sonst noch wissen was der Fehlereingrenzung dienlich ist?

 

- Gibt es Netbios/WINS Server im Netz

 

JA, den DC selbst.

 

- Wie sieht die Authentizierung der Domain aus NTLM etc. Ich hat da mal was verstellt und kriegte keine clients mehr in die Domain

 

Wurde ja inzwischen auch noch von anderen Usern hinterfragt:

 

"LM- und NTLM-Antworten senden"

 

- Du sagst dass der rsop Prozess (wenn die GPOs applied tierisch langsam sind).

- Wurden Änderungen in den GPOs gemacht ?

 

Ja, eine Test-GPO die aber nur an eine Test-OU gebunden wurde in der sich der Client aber zur Zeit nie befindet.

 

- WSUS würde ich fast ausschliessen, sonst stoppe den automatic update service und disable ihn nach reboot wird das wohl gleich sein

 

Der WSUS wurde von mir nur in dem Zusammenhang erwähnt als man mich nach Updates/Patches fragte. Als mögliche Fehlerquelle hatte ich den auch nicht im Focus.

 

...Ich würde auf dem DC alle default gruppenrichtlinien zurücksetzen (s. Gruppenrichtlinien - Übersicht, FAQ und Tutorials). Vorher kannst Du auch mit dem tool rsop.msc nachprüfen welche Policies applied werden.

 

Ich habe eben mal alle Verknüpfungen der GPO's entfernt, VMWare-Client neu installiert und versucht ihn in die Domäne zu heben:

--> gleicher Fehler.... :cry:

 

 

Viele Grüße

Mathias :)

[MathiasRR 10]

Moin moin,

 

Ich könnte mir auch vorstellen, daß es ein Problem mit den NTLM Einstellungen gibt. Prüf doch einmal die folgende Policy: "LAN Manager Authentication Level: Send NTLMv2 response only\refuse LM & NTLM" (siehe Microsoft Corporation)

Was ist dort eingestellt?

 

Habe ich schon in meinem vorigen Posting beantwortet, oder habe ich da jetzt was nicht an euren Fragen verstanden?

 

Bitte schaue auf einem Client, der Probleme beim Joinen hat, unterhalb von %SYSTEMROOT%\Debug nach der Datei "Netsetup.log". Bitte stell die einmal zur Verfügung. Dort kann man sehen, was während des Joins passiert - vielleicht ist etwas zu sehen.

 

04/29 05:20:41 NetpDoDomainJoin
04/29 05:20:41 NetpMachineValidToJoin: 'VM1'
04/29 05:20:41 NetpGetLsaPrimaryDomain: status: 0x0
04/29 05:20:41 NetpMachineValidToJoin: status: 0x0
04/29 05:20:41 NetpJoinDomain
04/29 05:20:41 	Machine: VM1
04/29 05:20:41 	Domain: ads
04/29 05:20:41 	MachineAccountOU: (NULL)
04/29 05:20:41 	Account: ads\Administrator
04/29 05:20:41 	Options: 0x27
04/29 05:20:41 	OS Version: 5.1
04/29 05:20:41 	Build number: 2600
04/29 05:20:41 	ServicePack: Service Pack 2
04/29 05:20:41 NetpValidateName: checking to see if 'ads' is valid as type 3 name
04/29 05:20:41 NetpCheckDomainNameIsValid [ Exists ] for 'ads' returned 0x0
04/29 05:20:41 NetpValidateName: name 'ads' is valid for type 3
04/29 05:20:41 NetpDsGetDcName: trying to find DC in domain 'ads', flags: 0x1020
04/29 05:20:41 NetpDsGetDcName: found DC '\\NORDSCHLEIFE' in the specified domain
04/29 05:20:41 NetpJoinDomain: status of connecting to dc '\\NORDSCHLEIFE': 0x0
04/29 05:20:41 NetpGetLsaPrimaryDomain: status: 0x0
04/29 05:20:41 NetpGetDnsHostName: Read NV Hostname: VM1
04/29 05:20:41 NetpGetDnsHostName: PrimaryDnsSuffix defaulted to DNS domain name: da.net
04/29 05:20:41 NetpLsaOpenSecret: status: 0xc0000034
04/29 05:20:41 NetpGetLsaPrimaryDomain: status: 0x0
04/29 05:20:41 NetpLsaOpenSecret: status: 0xc0000034
04/29 05:20:42 NetpManageMachineAccountWithSid: NetUserAdd on '\\NORDSCHLEIFE' for 'VM1$' failed: 0x8b0
04/29 05:20:42 NetpManageMachineAccountWithSid: status of attempting to set password on '\\NORDSCHLEIFE' for 'VM1$': 0x0
04/29 05:20:42 NetpJoinDomain: status of creating account: 0x0
04/29 05:21:03 NetpLdapBind: ldap_bind failed on \\NORDSCHLEIFE: 81: Server heruntergefahren
04/29 05:21:03 ldap_unbind status: 0x0
04/29 05:21:03 NetpSetDnsHostNameAndSpn: NetpLdapBind failed: 0x3a
04/29 05:21:03 NetpJoinDomain: status of setting DnsHostName and SPN: 0x3a
04/29 05:21:03 NetpJoinDomain: initiaing a rollback due to earlier errors
04/29 05:21:03 NetpGetLsaPrimaryDomain: status: 0x0
04/29 05:21:03 NetpManageMachineAccountWithSid: status of disabling account 'VM1$' on '\\NORDSCHLEIFE': 0x0
04/29 05:21:03 NetpJoinDomain: rollback: status of deleting computer account: 0x0
04/29 05:21:03 NetpLsaOpenSecret: status: 0x0
04/29 05:21:03 NetpJoinDomain: rollback: status of deleting secret: 0x0
04/29 05:21:03 NetpJoinDomain: status of disconnecting from '\\NORDSCHLEIFE': 0x0
04/29 05:21:03 NetpDoDomainJoin: status: 0x3a

 

 

...hmmm... Der LDAP-Fehler dass der Server herunter gefahren sei macht mich ja nen bissel stutzig.... Allerdings weiss ich nicht was er mir damit sagen möchte...

 

 

... Fortsetzung folgt....

[MathiasRR 10]

....Fortsetzung....

 

 

Der Hinweis von blub bezüglich des Netzwerktrace ist auch gut, vielleicht kannst Du den Vorgang einmal tracen.

 

??? Habe ich irgendwo was überlesen?

Muss gleich zur Arbeit, vielleicht kann mir nochmal jemand schreiben was ich da genau machen soll?

 

Bitte mach auch einmal einen LDIFDE Export des Client-Objekts, nachdem es mit einem roten X markiert ist, also deaktiviert (oder schau mittels ADSIEdit bzw. LDP) - hat der Client eine SID zugewiesen bekommen?

 

Aehm.... sorry, aber könnteste hier nen bissel konkreter schreiben wie ich das machen soll? Wie macht man einen LDIFDE Export und wie kann ich schauen ob ne SID vergeben wurde?

 

Ich gehe davon aus, daß der Benutzer, mit dem Du die Clients in die Domäne holst, Domain-Admin ist? In wie vielen Gruppen ist der Benutzer Mitglied? Geht es unter Umständen mit einem anderen Benutzer?

 

Jepp, er ist Admin. Ich habe es aber auch schon mit dem Domänen-Admin versucht.

 

Als nächsten Punkt solltest Du folgenden KB-Artikel prüfen: You receive an error message when you join a domain with Windows XP

 

???? TCP/IP ist selbstverständlich installiert und IPX hat der Client nie gesehen.

 

Wenn Du mit allem durch bist, melde Dich wieder. ;)

 

Meld, meld....:D

 

Es gibt ja auch noch andere User die sich Gedanken zu meinem Problem gemacht haben. DANKE dafür!

Ich muss mich jetzt aber auf den Weg zur Arbeit machen und komme nicht mehr dazu auch die anderen Beiträge alle zu beantworten.

Vielleicht klappt es heute Nachmittag, wenn mich der Job nicht wieder zu lange in Beschlag hält.

 

Viele Grüße

Mathias :)

[blub 115]

Hallo,

Hol dir unter Microsoft Download Center mal das Tool "portquery". Versuche damit mal an einem Client, ob der LDAP-Port des DCs erreichbar ist:

 

portqry -n <DCname> -e 389 und -p TCP

portqry -n <DC IPAdresse> -e 389 -p TCP

 

cu

blub

[Jim di Griz 13]

... auch diese Frage wurde schon geschätzte 12x beantwortet. ;)

 

Gruß olc

 

naja, in diesem beitrag nicht einmal ausser dem lapidaren hinweis das eventlog sei absolut sauber.

zumindest irgendeine an oder abmeldung sollte ja wohl auftauchen und ein fehler an dieser stelle wird "normalerweise" auch geloggt