Benutzeranmeldung dauert ewig

[ToX1c 10]

Hallo,

 

um unser Firmennetzwerk ein wenig sicherer zu machen, wurde ich beauftragt mittels IPsec eine Portsperre einzurichten, die mittels ActiveDirectory und Gruppenrichtlinien auf unsere Clients gespielt wird.

Ich habe nun eine solche Testumgebung aufgebaut und festgestellt, dass wenn ein Rechner sich in dieser Umgebung anmelden will der Dialog "Benutzerdefinierte Einstellungen werden übernommen" 5min. oder länger stehen bleibt, bis man endlich zum Desktop gelangt. Meine Vermutung ist das noch irgendein Port gesperrt ist den man braucht um sich anzumelden...

Ich habe die Sicherheitsrichtlinie im moment so konfiguriert, dass folgende Ports freigegeben sind: 20 (FTP), 25 (SMTP), 53 (DNS), 67 (DHCP), 80 (HTTP), 110 (POP3), 137-139 und 445 (NETBIOS), 389 (LDAP), 1025

 

Woran könnte es also liegen, das bei den Clients die sich in dieser Testumgebung befinden die Anmeldung so lange dauert?

 

Freundliche Grüße

 

ToX

[Velius 10]

Hi und willkommen

 

Da fehlt mindesten noch LDAP Global Catalog (TCP 3268), Kerberos V5 (UDP/TCP 88) und DHCP (UDP 67) ist blos der Request, der Replay läuft auf UDP 68....

 

 

Sonst gibt's noch andere Threads hier im Board, wo ausführlicher alle von Windows/AD benötigten Ports beschrieben sind.

 

 

 

Gruss

Velius

[Christoph35 10]

Zu den von Velius genannten ports kommen dann ggf. noch RPC (135) und High Ports, wobei man den High Port auch genau definieren kann (einen DWord Wert namens "tcp/ip port" und portnummer > 1024 anlegen unter hklm/system/currentcontrolset/services/ntds/parameters/).

 

Christoph

[ToX1c 10]

Hi,

 

erstmal danke für die schnelle Antwort!

Ich habe mittels IPsec nur den TCP-verkehr blockiert, d.h. UDP-Verkehr sollte kein Problem sein.

Ich habe grade die TCP-Ports 3268 (LDAP Global Catalog) und 88 (Kerberos V5) freigegeben und es funktioniert leider immer noch nicht :(

 

Grüße

 

ToX

[Velius 10]

Die Frage ist ja wohl auch von wo nach wo, bzw. wo werden die Richtlinien angewandt, und sind sie inbound oder outbound....

[ToX1c 10]

Ich hab bisher alle Richtlinien so angelegt, dass sie Inbound sowie Outbound anfragen stellen können..

Man kann also von der eigenen IP nach aussen hin über jeden x-beliebigen Port den Port 80 am anderen Teilnehmer ansprechen und jeder Teilnehmer kann über seinen Port 80 jeden x-beliebigen Port an meiner lokalen Maschine ansprechen...

 

als anleitung dazu diente mir übrigens http://www.iuventa.net/doku/port_absichern_windows_2000_ipsec.html falls das weiter hilft ;)

 

In der userenv.log unter C:/WINNT/Debug/UserMode/ sind folgende Einträge zu finden.

 

USERENV(fc.f8) 14:05:34:822 UnloadUserProfile: received a NULL hProfile.

USERENV(e0.c8) 14:07:57:177 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.c8) 14:09:00:869 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.c8) 14:10:04:560 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.c8) 14:11:08:252 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.c8) 14:11:08:252 GetUserGuid: Failed to get user guid with 1722.

USERENV(e0.c8) 14:12:11:443 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.c8) 14:13:15:134 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.c8) 14:14:18:826 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.c8) 14:15:22:517 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.c8) 14:15:22:517 GetUserGuid: Failed to get user guid with 1722.

USERENV(e0.25c) 14:16:46:739 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.25c) 14:17:50:430 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.25c) 14:18:54:122 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.25c) 14:19:57:813 MyGetUserName: GetUserNameEx failed with 1722.

USERENV(e0.25c) 14:19:57:813 ProcessGPOs: MyGetUserName failed with 1722.

USERENV(3c8.278) 14:21:03:508 MyGetUserName: GetUserNameEx failed with 1722.

 

Desweiteren bekomme ich in der Ereignisanzeige den Fehler mit der Ereignis-ID: 1000 zu sehnen (Der Benutzer oder der Computername kann nicht ermittelt werden Zurückgegebener Wert (1722).)

Laut dem Microsoft Artikel liegt es am DNS aber ich habe gerade nachgeguckt und es ist der richtige DNS Server in den TCP/IP Eigenschaften eingetragen.