Securepoint Support Forum

Ich habe ein Problem mit der NTLM funktion unter Windows 2008R2. Leider bekomme ich da keine Verbindung zum Internet. Unter Windows 2008 ging das ohne Probleme.
Es kommt immer ein Fenster wo Benutzername und Passwort eingegeben werden soll. Leider gehen keine zugänge die in der Domain vorhanden sind. Stelle ich es auf Active Directory kann ich die zugangsdaten eingeben und ich bekomme eine Verbindung zum Internet. Die Konfiguration habe ich über das Webinterface vorgenommen da es im Manager bis jetzt Probleme gab.

PS: Wir der Manager überhaupt noch weiter entwickelt. Ich hoffe mal ja da er für mich sehr wichtig ist und mit Ihm bedeutent einfacher mehrere Firewalls zu bedienen als das umständliche Webinterface.

Ein Anmeldefenster erscheint bei aktivierter NTLM-Auth nur, wenn der Rechner nicht in der konfigurierten Domände ist oder der Client keine NTLM-Informationen an den Proxy sendet.
Haben Sie den Proxy neugestartet, nachdem Sie mit der Authentifizierung "rumgespielt" haben?

Zum Manager:
Für den Manager in der jetzigen Form werden keine neuen Features implementiert. Er wird in Zukunft durch ein ähnliches Produkt ersetzt werden.

Den Proxy Dienst und die ganze Firewall habe ich nach dem konf. mehrfach neugestartet. Leider ohne Erfolg. Die NTLM zum Proxy geht auch nicht vom Domaincontroller selber. Was könnte ich noch testen um den Fehler eingrenzen zu können.

Hallo,

bitte loggen sie sich mal per root an der FW ein.

Dann versuchen sie die FW in die Domäne zu integrieren. Sollte dies Fehler auswerfen, hilft wohl nur eine suche bei google.

net ads join -U Administrator

Wir konnten den Fehrler etwas eingrenzen. Wir haben hier den aufbau beim Kunden nachgestellt und es kommt der gleiche fehler. Uns ist aufgefallen das der Kerberos Dienst sich nicht starten lässt und somit ist dies Kerberos funktion auch nicht gegeben. Leider steht im log keine Fehlermeldung drin warum der dienst nicht startet. Woran könnte das liegen

Führen Sie den Befehl aus, den carsten gepostet hat - der gibt dann eine Fehlermeldung, wenn z.B. die falsche Arbeitsgruppe angegeben wurde.

Using short domain name -- STF-NDS
Joined 'FIREWALL' to realm 'stf-nds.local'
Es kommt immer diese meldung wenn ich den befehl ausführe

Moin

ich schieße hier mal ins Blaue... kann es nicht sein, dass beim Windows Server 2008 R2 die Security Policies verändert wurden und NTLM mal weg vom Fenster ist? Ich würde hier mal die entsprechenden Policies überprüfen... Es gibt auch gute Gründe wieso man NTLM nicht mehr verwenden sollte.

Allerdings verstehe ich eine Sache nicht... unter "Externe Authentifizierung" steht, dass es sich um Kerberos handelt, ansonsten wird hier von NTLM gesprochen. Soweit ich weiß, sind das zwei Paar Schuhe?!

Viele Grüße!

http://de.wikipedia.org/wiki/NTLM hat geschrieben:Ein alternatives, offenes Protokoll ist Kerberos, welches auch unter Windows ab Server 2000 und XP SP1 standardmäßig zum Einsatz kommt.

Viele Möglichkeiten zum Debuggen haben wir nichtmehr.
Die Kommunikation zum Server ist OK, sonst würden Sie nicht mit "net ads join" der Domäne beitreten können.
Ob Sie überhaupt "irgendwas" auf der Domäne dürfen, prüfen Sie folgendermaßen: Mittels prüfen Sie jetzt, ob der Dienst wirklich gestartet wurde. Ist das der Fall geht es weiter: Statt der Raute steht am Anfang der Zeile Jetzt ein Dollarzeichen: listet schliesslich alle Gruppen bzw User im AD auf. Wenn das alles funktioniert, kann es fast nur ein Berechtigungsproblem auf dem Server selber sein.

Moin
Ich hatte folgendes Problem:
NTML Auth an Proxy funktionierte nur mit der Einstellung "Alles erlauben". Habe ich eine Gruppe ausgewählt, ging nichts mehr.

Daher habe ich eben die Befehle nacheinander ausgeführt.
wbinfo -> hat nichts angezeigt -> könnte obiges Verhalten erklären

Jetzt lässt sich leider der Kerberos Dienst nicht mehr starten. Neustart hat nichts gebracht, net ads join Befehl ist ok (Computerkonto wird auch angelegt, habe dieses testweise gelöscht), net ads leave funktioniert nicht.

Was nu? ;-)

Viele Grüße!

Was sagt ?

# winbindd -i
winbindd version 3.3.4 started.
Copyright Andrew Tridgell and the Samba Team 1992-2009
initialize_winbindd_cache: clearing cache and re-creating with version number 1

...danach kommt nichts mehr. während der befehl läuft, ist der kerberos dienst gestartet, allerdings läuft die authentifizierung über den proxy weiterhin nicht.

bei mir läst sich der Kerberos Dienst auf der Firewall nicht starten. Betriebssystem ist ein Windows 2008 R2. Im Ereignissprotokoll unter Windows stehen folgende Meldungen wenn der Dienst auf der Firewall gestartet wird:

Protokollname: Security
Quelle: Microsoft-Windows-Security-Auditing
Datum: 22.02.2010 20:28:16
Ereignis-ID: 4634
Aufgabenkategorie:Abmelden
Ebene: Informationen
Schlüsselwörter:Überwachung erfolgreich
Benutzer: Nicht zutreffend
Computer: Server.stf-nds.local
Beschreibung:
Ein Konto wurde abgemeldet.

Antragsteller:
Sicherheits-ID: STF-NDS\\administrator
Kontoname: Administrator
Kontodomäne: STF-NDS
Anmelde-ID: 0xb19c05b

Anmeldetyp: 3

Dieses Ereignis wird generiert, wenn eine Anmeldesitzung zerstört wird. Es kann anhand des Wertes der Anmelde-ID positiv mit einem Anmeldeereignis korreliert werden. Anmelde-IDs sind nur zwischen Neustarts auf demselben Computer eindeutig.
Ereignis-XML:



4634
0
0
12545
0
0x8020000000000000

454651


Security
Server.stf-nds.local



S-1-5-21-2978258790-467058405-2440926156-500
Administrator
STF-NDS
0xb19c05b
3



Protokollname: Security
Quelle: Microsoft-Windows-Security-Auditing
Datum: 22.02.2010 20:28:16
Ereignis-ID: 4624
Aufgabenkategorie:Anmelden
Ebene: Informationen
Schlüsselwörter:Überwachung erfolgreich
Benutzer: Nicht zutreffend
Computer: Server.stf-nds.local
Beschreibung:
Ein Konto wurde erfolgreich angemeldet.

Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0

Anmeldetyp: 3

Neue Anmeldung:
Sicherheits-ID: STF-NDS\\administrator
Kontoname: Administrator
Kontodomäne: STF-NDS
Anmelde-ID: 0xb19c05b
Anmelde-GUID: {00000000-0000-0000-0000-000000000000}

Prozessinformationen:
Prozess-ID: 0x0
Prozessname: -

Netzwerkinformationen:
Arbeitsstationsname: FIREWALL
Quellnetzwerkadresse: 192.168.0.254
Quellport: 46072

Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): NTLM V1
Schlüssellänge: 128

Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.

Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".

Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).

Die Felder für die neue Anmeldung geben das Konto an, für das die Anmeldung erstellt wurde, d. h. das angemeldete Konto.

Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.

Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
- Die Anmelde-GUID ist ein eindeutiger Bezeichner, der verwendet werden kann, um dieses Ereignis mit einem KDC-Ereignis zu korrelieren.
- Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
- Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.
Ereignis-XML:



4624
0
0
12544
0
0x8020000000000000

454650


Security
Server.stf-nds.local



S-1-0-0
-
-
0x0
S-1-5-21-2978258790-467058405-2440926156-500
Administrator
STF-NDS
0xb19c05b
3
NtLmSsp
NTLM
FIREWALL
{00000000-0000-0000-0000-000000000000}
-
NTLM V1
128
0x0
-
192.168.0.254
46072



Protokollname: Security
Quelle: Microsoft-Windows-Security-Auditing
Datum: 22.02.2010 20:28:16
Ereignis-ID: 4672
Aufgabenkategorie:Spezielle Anmeldung
Ebene: Informationen
Schlüsselwörter:Überwachung erfolgreich
Benutzer: Nicht zutreffend
Computer: Server.stf-nds.local
Beschreibung:
Einer neuen Anmeldung wurden besondere Rechte zugewiesen.

Antragsteller:
Sicherheits-ID: STF-NDS\\administrator
Kontoname: Administrator
Kontodomäne: STF-NDS
Anmelde-ID: 0xb19c05b

Berechtigungen: SeSecurityPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeTakeOwnershipPrivilege
SeDebugPrivilege
SeSystemEnvironmentPrivilege
SeLoadDriverPrivilege
SeImpersonatePrivilege
SeEnableDelegationPrivilege
Ereignis-XML:



4672
0
0
12548
0
0x8020000000000000

454649


Security
Server.stf-nds.local



S-1-5-21-2978258790-467058405-2440926156-500
Administrator
STF-NDS
0xb19c05b
SeSecurityPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeTakeOwnershipPrivilege
SeDebugPrivilege
SeSystemEnvironmentPrivilege
SeLoadDriverPrivilege
SeImpersonatePrivilege
SeEnableDelegationPrivilege



Protokollname: Security
Quelle: Microsoft-Windows-Security-Auditing
Datum: 22.02.2010 20:28:16
Ereignis-ID: 4776
Aufgabenkategorie:Überprüfung der Anmeldeinformationen
Ebene: Informationen
Schlüsselwörter:Überwachung erfolgreich
Benutzer: Nicht zutreffend
Computer: Server.stf-nds.local
Beschreibung:
Es wurde versucht, die Anmeldeinformationen für ein Konto zu überprüfen.

Authentifizierungspaket: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Anmeldekonto: Administrator
Arbeitsstation: FIREWALL
Fehlercode: 0x0
Ereignis-XML:



4776
0
0
14336
0
0x8020000000000000

454648


Security
Server.stf-nds.local



MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Administrator
FIREWALL
0x0

hat jemand noch ein paar tips

Hallo Stephan

Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): NTLM V1
Schlüssellänge: 128

Ich werde den Verdacht nicht los, dass die Securepoint auch NTLM sendet, was erstens seit Jahren nicht mehr empfohlen wird und ab Windows Server 2008 auch standardmäßig auf NTLMv2 eingeschränkt ist (kannst du in der Default Domain Policy und Default Domain-Controller Policy sehen). Hier würde der DC eventuell den Prozess killen... so würde ich mir das nun erklären, sicher bin ich mir nicht und würde vorschlagen, dass du deine Events bei www.eventid.net nachschlägst und die Antworten in Microsoft Foren / Newsgroups mal andiskutierst.
Ich habe ja ein ähnliches Problem, kann mich aber zur Zeit wegen diverser Projekte nicht kümmern... Ich werde den Support aber in 1-2 Wochen mal befragen, eventuell poste ich dann hier die Ergebnisse.

Trotzdem würde mich nochmal interessieren, ob der "Kerberos Daemon" in der Securepoint wirklich ein Kerberos Daemon ist oder halt generell alle Authentifizierungsformen, die man bei Microsoft vorfinden kann, nutzt (also LM, NTLM, NTLMv2, Kerberos). Wie gesagt, ich habe nur leider grad keine Zeit mich mit Daemons aus der Linuxwelt zu beschäftigen

Viele Grüße!

Wertes Sercurepoint Team, welche NTLM Version wird auf der Securepoint ausgeführt. Ist das noch die Version 1 oder schon Version 2

Sry für die späte Antwort, aber wir sind nicht allwissend hier Zum Glück gibbet Google: Klick
Da der Kerl das entwickelt, glaub ich ihm einfach mal (auch wenn es sonst nicht viele Informationen im Interweb gibt).

Wir haben das jetzt nochmal auf 2 blanko Maschienen nachgestellt. 1. mit Windows 2008 Std. und die 2. mit Windows 2008 R2 Std.
Der 1. Server ging die NTLM ohne irgend welcher Probleme, doch bei dem 2. Server ging wieder nichts. Die Firewall wurde zwar dem ADS hinzugefügt aber unter sicherheit sind immer noch die Fehlermeldungen gekommen. Der Dienst lies sich somit nicht starten.
Uns ist aufgefallen das die Domain Controller Richtlinien von Server 2 etwas anders ausgesehen hat als die von Server 1
Wir haben diese dann angeglichen da dort auch der eintrag "Nur NTLMv2-Antwort senden" gefällt hat.
Leider hat das auch nicht zum gewünschten Erfolg gebracht.
Hat einer von euch noch eine Idee wo es an dem R2 Server liegen kann??

Welche Version von Squid ist in der Firewall integriert??

diese da

Da haben wir ja den Fehler gefunden. Windows 2008R2/Windows 7 wird erst mit der Version 2.7 STABLE7. Die Aktuellste wäre ja die 3.0 STABLE24.
Ist da ein Update geplant um das dann auch auf Windows 2008R2/Windows7 richtig zum laufen zu bringen??

Wird an diesem Problem noch gearbeitet?? Ein status wäre nicht ganz schlecht

Ich kann Ihnen nicht sagen, ob und wenn ja für wann ein Update des Squid geplant ist.
Desweiteren finde ich ehrlich gesagt keine Angabe darüber, dass dieses konkrete Problem mit der von Ihnen genannten Version beseitigt ist. Das Changelog für 2.7STABLE7 sagt das da:

- Windows port: Added support for Windows 7, Windows Server 2008 R2 and later

Das bezieht sich wohl auf die Windows-Version des Squid und nicht auf etwaige Inkompatibilitäten der Linux-Version mit Windows.

Muss man nach dem Update auf 10.1 (8831) noch irgend welche Einstellungen an der Firewall bzw. am Windows 2008R2 Server vornehmen. Beim mir Startet immer noch der dienst ganz kurz und beendet sich gleich wieder.

Hallo,

haben Sie den Dienst mal manuell von Hand gestartet (als root)?

Dann in das Verzeichnis cd /var/locks wechseln und dort die Dateien

- winbindd.pid
- winbindd_cache.tdb

löschen.