VPN Authentifizierung mit RSA/ACE Server und SecurID Token

#1 Ich habe die Erfahrung gemacht, dass viele Leute Probleme mit dem RSA Zeug haben.
ALSO RUHIG WAS POSTEN, ICH ANTWORTE 1000%'ig, noch den selben TAG.
Hallo, ich habe ein Problem mit bei der VPN-Authentifizierung mit dem RSA/ACE Server 6.0.

Ich habe schon alles eingerichtet, den RSA/ACE Server, Benutzer aus dem LDAP Verzeichnis, Tokens initialisiert und Agent Hosts angelegt.
Meine Domäne:
Windows 2003 Server Enterprise Edition und 3 XP-Clients

Das Problem:
Auf dem besagten Client läuft ein ACE Agent, den ich wie in den Dokus von RSA beschrieben, angelegt habe.

Unter Start --> RSA ACE Agent --> Authentication Test
kann man nun eine Testauthentifizierung vornehmen, wobei zugleich das node secret dadurch erzeugt wird. Tolle Sache, denn es klappt. Auf dem Log Monitor erhält man folgende Meldung:

blabla User/Client 000628646/User
blabla Passcode accepted MyServer
blabla User/Client ---->
blabla node secret sent to agent host MyServer

Jetzt gehe ich doch davon aus, dass Client und Server das node Secret ausgetauscht haben. Wie in der Doku beschrieben habe ich den RRAS Server und eine entsprechende VPN-Richtlinie erstellt und konfiguriert.
Außerdem habe ich ein Verbindungsobjekt für meine VPN-Verbindung auf dem Client erstellt, über die ich mich nun dem Server gegenüber authentifiziere (KEIN RADIUS lediglich RRAS mit RSA EAP)

ich gebe anschließend Benutzer und Passcode ein...
Es erscheint nach einer Weile einfach die Meldung ACCESS DENIED

WARUM???!!!! Die Testauthentifizierung funktioniert doch auch?

Es ist nicht so, dass der Benutzer nicht erkannt wird oder ähnliches. Komischer Weise sehe ich auf dem Log Monitor auf dem Server keine Meldung, dass was passiert. Warum?
Wenn ich einen neuen Agent host hinzufüge und zwar diesmal meinen Server, dann bekomme ich auch eine Meldung und zwar "Node verification failed"

Anschließend kann man in der Systemsteuerung natürlich den RSA ACE/Agent starten und unter "Erweitert" das Node Secret löschen, den Haken auf dem Server deaktivieren und wieder eine Testauthentifizierung starten, damit ein neues Node Secret erzeugt wird. Dies jedoch löst nicht mein Problem.

Ich habe auch ein anderes VPN-Verbindungsobjekt auf dem Desktop, mit dem ich mich Zertifikatsbasiert mit einer Smartcard über VPN am DomainController authentifiziere und das klappt einwandfrei. (Ich hab ne Zertifizierungsstelle und ne komplette Smartcard basierte PKI in der Domäne eingerichtet).

Kann mir bitte jemand helfen? Ich weiß nicht weiter. Warum kann ich mich über VPN nicht am ACE Server authentifizieren?

Gruß Basti[/b]

_________________________________________________________________
Hallo,

ich habe das Problem gelöst.
Der Client an der Domäne braucht lediglich den RSA Security Client, der Agent Host muss der Server sein.
Anschließend eine Testauthentifizierung machen, um das node secret zu erzeugen.
Jetzt muss in der systemsteurerung noch folgendes eingestellt werden:

RSA/ACE Agen starten und den Button Send domain with username to RSA ACE/server deaktivieren!

Warum?

Ganz einfach!

Wenn man einen User auf dem Agent host anlegt beispielsweise Heinz, so kennt der Agent Host auch nur Heinz, beim einloggen - logisch.

Is der eben beschriebene Button jedoch gesetzt (Haken), dann wird beim anmelden die Domäne dem Benutzernamen hinzugefügt. Heinz meldet sich dann also als PKI/Heinz an (wenn die Domäne PKI heißt). Der ACE Server holt sich dann aus´dem ActiveDirectory (is ja ne Art LDAP) den User. Der User den der Server jedoch kennt heißt Heinz und nicht PKI/Heinz, was dazu führt, dass die Authentifzierung fehl schlägt - und zwar mit der Fehlermeldung User not in Database oder user not on Agent Host.

Also:

Den RSA ACE/Agent nur auf dem Server installieren
(bei der Installation Remote Authentification Server wählen)

Den RSA Securtiy EAP Client nur auf dem Client installieren

Den Agenthost auf dem Server anlegen. Der Agent Host ist der Server. Benutzer auf dem Agent Host aktivieren, bzw. die Gruppe, in der er sich befindet

testauthentifizierung starten
node secret wird erzeugt und am Agent Host (dem Server in dem Fall) gespeichert. das node secret ist ein symmetrischer Schlüssel 3DES oder ähnliches, über welchen die Daten auf dem VPN-Kanal verschlüsselt werden.

nun kann man sich vom Client aus über das erstellt Verbindungsobjekt am Server authentifizieren.

Wenn Fragen auftauchen, bitte fragt mich. Ich versuche gern zu Helfen. Ich habe mich jetzt 4 Monate mit Smartcards von Kobil Containerverschlüsselung Singel Sign On mit Zertifikaten und eine Woche mit diesem RSA/ACE SecurID Kram beschäftigt und habe alles am laufen.
Ich schaue täglich ein Paar mal hier im Forum vorbei.

Gruß Basti

#2 Hallo Basti

Ich hoffe, Du kannst mir weiterhelfen. Ich bin seit Ewigkeiten am Versuchen, bei einem Kunden RSA Securid einzurichten (ACE Server/Manager 6.0, SID700)

Die Konfiguration sieht folgendermassen aus:

-Terminalserver1 (Memberserver)
-Terminalserver2 (Memberserver)
-Exchangeserver (Memberserver)
-Daten-/Appl-Server (DC)
-Printserver (DC)

Alle Server sind mit Win2003 Server Standard SP1 installiert.

Den Datenserver werde ich als Memberserver konfigurieren und das AD nur noch auf dem Printserver laufen lassen, da ich seit kurzem noch Probleme mit der Replikation habe...

Kannst Du mir mal Schrittweise erklären, auf welchen Server was genau installiert werden muss, und in welcher Reihenfolge? Ich kriege das einfach nicht hin, die Benutzer (anmeldung an Terminalserver) werden nicht nach dem Tokenpasswort bzw. Pin gefragt, und eine Testauthentifizierung scheitert ebenfalls jedesmal, immer steht da Falsches Passwort.

Auch bezüglich den Zertifikaten erstellen habe ich irgendwie nicht den Durchblick, wie ich diese nachher verteilen muss. Ich habe zwar schon mehrere Male versucht, nach Anleitung zu installieren, aber jedesmal scheiterts an der Anmeldung, die nicht funktioniert. Und die Anleitung ist auch unübersichtlich.

Irgendwo mache ich da was falsch. Hat das evtl. was mit SP1 zu tun?
Kann ich die RSA Server Applikation auch auf einer XP-Maschine installieren?

Ich müsste einfach mal eine kurze Anleitung haben, was in welcher Reihenfolge wo installiert werden muss.

Auf jeden Fall danke für jede Antwort im voraus!!!

Gruss
Michel

#3 Hallo Michel,

ich habe, RSA SecureID lediglich für die VPN-Authentifizierung eingerichtet und ein kleines HOWTO dafür geschrieben. Dies stelle ich Dir zur Verfügung. Ich hoffe, es kann dir Helfen. Ich denke, dass sich die Domänenauthentifikation noch einfacher implementieren läßt als eine VPN-Authentifikation mit RSA. Ich denke, wenn Du dann erstmal verstanden hast, wo der Agent Host und welche Komponenten auf Client und Server intalliert werden müssen, dürfte es bei dir auch klappen.

Wichtig ist, dass du begreifst, dass deine Memeberserver nur als AGENTS agieren.

Dein Domain Controller sollte den RSA/ACE Server stellen, sowie den AGENT Host darstellen. Als Agent Host kannst du auch einen anderen Server (Domaincontroller) deiner Domäne verwenden, steht aber auch irgendwo im HOWTO...

Ein Problem der Kompatbilität bezüglich der XP Versionen SP1 gibt es nicht oder sind mir unbekannt
Die RSA Server Applikation sollte nicht auf einem Clientrechner installiert sein, dafür ist sie nicht gedacht.

Hier das HOWTO:

Einrichten eines RSA/ACE Server mit SecurID-Token für VPN-Zugriff
Installation der Komponenten:

1. RSA/ACE Server auf dem Domain Controller
2. Hierfür müssen während der Installation die Server Zertifikate, Lizenzen und Serverschlüssel für den ACE Server bereitgehalten werden, da während der Installation danach gefragt wird.
3. Authentication Agent installieren. Für den ausschließlichen Gebrauch eines gesicherten VPN folgende Komponenten:
o Für den Server: ausschließlich den Remote Authentication Server
o Für den Client: ausschließlich den RSA Security EAP Client

Konfiguration der Token:

· Start – Programme – RSA ACE Server – Database Administration Host Mode starten

· Nun können die Token Seeds importiert werden. Dies sind Initialwerte für die ausgelieferten SecurID Token, welche der Server kennen muss, da dieser ebenso, wie die Token selbst, in der Lage sein muss pseudozufällige Tokencodes zu berechnen.

· Unter dem Menüpunkt Token – Import Token… kann dies vorgenommen werden

o Die Quelle ist die beiliegende CD oder Diskette, auf welcher sich eine entsprechende Datei Excel-Liste befindet, welche die Saat enthält.
o Anschließend kann man sich die Token unter List Tokens… anschauen
o Unter Edit Token können noch Einstellungen vorgenommen werden
§ Resynchronisation, um Token-Zeit mit Server-Zeit zu synchronisieren
§ Art der Authentifizierung: entweder nur der Tokencode oder mit Passcode (Pin + Tokencode)
§ Unter Assign Token… können Token einem User zugewiesen werden, dies kann jedoch auch unter dem Punkt User – Edit User… vorgenommen werden. Bevor die jedoch geschehen kann müssen natürlich erst einmal User angelegt werden

Konfiguration der User:
· Unter dem Menüpunkt User – LDAP-Users – Add Synchronization… kann nun eine LDAP Synchronisation für einen/mehrere User angelegt werden
o Unter Windows ist der LDAP-Server Typ das AD
o Der LDAP Host ist der Server, auf dem sich das AD befindet
o Unter LDAP User Search Information: wird nun der Suchpfad angegeben, unter dem sich der User befindet. Hier bei mir: ou=pki_user,ou=accounts,dc=pki,dc=test
o Unter LDAP Query Filter: können Filter gesetzt werden, um Zugriffe auf das AD zu beschränken. Wenn keine speziellen Filter gesetzt werden müssen, folgendes eingeben: objectclass=*
o Unter LDAP Authentication wird nach einem bestehenden User und seinem Passwort gefragt, über welchen der LDAP zugriff autorisiert wird. Hierfür einen bereits im AD bestehenden User auswählen und das Passwort eingeben
o Unter dem Punkt Job Options können noch zusätzliche Synchronisationen von Benutzern und Gruppen denen sie angehören vorgenommen werden
o Unter Job Information kann ein Name für die Synchronisation vergeben werden, sowie der Abstand der Intervalle in denen synchronisiert wird. Ein Abstand von 24 Stunden ist die Regel. Um die LDAP Synchronisation zu testen kann das Intervall kurzfristig auf eine Minute eingestellt werden, um die Wartezeiten zu verkürzen
o Unter User – Edit User... können nun Benutzer konfiguriert werden. Voraussetzung ist, dass die Synchronisation läuft und den Status OK zurückgeliefert hat. Um sich eine Liste der zur Verfügung stehenden Benutzer anzeigen zu lassen, kann im Namensfeld das *-Zeichen verwendet werden
o Anschließend erhält man eine Liste der Benutzer aus dem AD. Mit einem Doppelklick auf den entsprechenden Benutzer kann ausgewählt werden
o Unter Assign Token… kann nun ein Token dem User zugewiesen werden
o Die Punkte Group Memberships… und Agent Host Activations… können unter auch unter dem Menüpunkt Agent Host konfiguriert werden. Voraussetzung ist, dass Gruppen angelegt sind und ein Agent Host konfiguriert ist

· Unter dem Menüpunkt Group können Gruppen angelegt werden und Mitglieder aus dem AD hinzugefügt werden.
· Somit kann man eine einzige Gruppe auf einem Agent Host aktivieren, welche schon alle User enthält, die Zugriff über VPN haben dürfen, ohne die User direkt zu aktivieren.

Konfiguration des Agent Host:
· Unter dem Menüpunkt Agent Host – Add Agent Host… kann dieser konfiguriert werden
· Der Agent Host ist in der Regel der Rechner, auf welchem der Authentication Agent installiert wurde
· Eine Authentifizierung läuft so ab, dass der Agent den Passcode und Benutzernamen entgegennimmt und an den ACE Server weiterleitet, dieser entscheidet anschließend, ob eine Verbindung zugelassen wird oder nicht, leitet diese Information an den Agent weiter, welcher wiederum dem Client mitteilt, ob der Zugriff gewährt oder verweigert wurde.
· Unter Name: den Namen des Servers angeben, auf welchem sich der Authentication Agent befindet (bei mir ein und der Selbe Server). Anschließend sollte unter Network address: die IP-Adresse automatisch angezeigt werden
· In einer Windows Domäne ist der Agent Host ein normaler Net OS Agent
· Das Kästchen Node Secret Created ist noch ausgegraut
· Das Kästchen Enable Windows Password Integration sorgt dafür, dass ein Benutzer nach der Authentifizierung mit einem SecureID Token nicht noch zusätzlich Windows Anmeldedaten eingeben muss.
· Das Kästchen Create Verifiable Authentications wird benötigt, wenn die Authentifizierung über einen Webserver läuft, der Mitglied einer Domäne ist. Der Webserver selbst lässt die Authentifizierung zu, jedoch verlangt der Domaincontroller zusätzlich die Windows Anmeldedaten des Users, da der Webserver nicht in der Lage ist die SecurID Authentifizierung über einen geschützten Domaincontroller hinweg vorzunehmen. Genaueres dazu befindet sich im Whitepaper WinAgentAdmin.pdf von RSA auf Seite 59.
· Über die Group Activations… und User Activations… können Benutzer und Gruppen von Benutzern für den VPN Zugriff aktiviert werden. Kennt der Agent eine Gruppe oder einen Benutzer nicht, wird dieser keinen Zugriff erhalten.
· Mit dem Button Assign Acting Servers… wird der Server dem Agent Host zugewiesen, welcher als ACE Server konfiguriert wurde (in meinem Fall der selbe Rechner, wie der Agent Host)

Konfiguration des Remote Authentication Servers (Routing und RAS):

Hier VPN-Server, IPSec-Endpunkt Zertifikat geschützt mit L2TP als Tunneltyp und 128 Bit Kanalverschlüsselung. HIERFÜR IST ES WICHTIG, DASS JEDE MASCHINE EIN IPSEC-ZERTIFIKAT BESITZT (FÜR ENDPUNKTAUTHENTIFIZIERUNG).
Alternative ist normales PPTP, da L2TP IPSec verlangt.

· Start – Programme Verwaltung – Routing und RAS
· Rechtsklick auf den Server – Eigenschaften
· Allgemein:
o RAS Server
· Sicherheit:
o Authentifizierungsanbieter: Windows Authentifizierung
o Authentifizierungsmethoden: Nur EAP alle anderen deaktivieren
o Kontoanbieter: Windows Kontoführung
· IP:
o Falls der Server auch DNS-Dienste übernimmt folgende Einstellungen:
§ IP-Routing aktivieren
§ IP-basiertes RAS zulassen
§ Der Server kann über DCHP IP-Adressen zuweisen aktivieren

RAS-Richtlinien:
§ Eigene Richtlinie erstellen oder vorhandene bearbeiten
§ Einstellungen:
o Über Hinzufügen folgende Attribute auswählen:
§ NAS-Port-Type à Virtuell (VPN)
§ Windows Groups à Falls nur bestimmte Nutzer einer Gruppe den VPN-Zugang nutzen dürfen
§ Tunnel Type à L2TP
§ Profil bearbeiten…:
o IP:
§ Servereinstellungen definieren die IP-Adresszuordnung
o Einwähleinschränkungen:
§ Zugriff nur mit diesen Medien gewähren (NAS-Porttyp): Virtuell (VPN)
o Verschlüsselung:
§ Stärkste Verschlüsselung (128 Bit)
o Authentifizierung:
§ Ausschließlich EAP alle anderen deaktivieren
§ EAP-Methoden: RSA Security EAP

Konfiguration des Client PC’s für Remote Access:

Wichtig ist die Installation des RSA Security EAP Client auf dem Client-Rechner.

Erstellen eines VPN-Verbindungsobjektes auf dem Client:
· Start – Einstellungen – Rechtsklick Netwerkverbindungen öffnen
· Unter Netzwerkaufgaben: Neue Verbindung erstellen – Weiter
· Den Anweisungen des Assistenten für neue Verbindungen folgen
· Für VPN: Verbindung mit dem Netzwerk am Arbeitsplatz herstellen – Weiter
· VPN-Verbindung wählen – Weiter
· Anzeigenamen für die Verbindung eingeben – Weiter
· Falls die Einwahl ins Netz über ISDN oder Modem erfolgt: Automatisch diese Anfangsverbindung wählen (Je nach Einstellung, Netzwerk, Provider etc. Unterschiedlich). Sonst keine Anfangsverbindung wählen
· Ziel: Servername, bzw. Ziel-IP angeben – Weiter
· Den Anweisungen weiter folgen
· Das Verbindungsobjekt wird erstellt
· Es sind noch einige weitere Einstellungen nötig
o Rechtklick auf das Verbindungsobjekt – Eigenschaften
o Sicherheit:
§ Erweiterte Sicherheitsoptionen sind notwendig, die typischen abwählen
§ Button Einstellungen klicken
§ Anmeldesicherheit nur EAP verwenden, alle anderen abwählen
§ Hier die RSA Security EAP Verschlüsselung wählen
o Netzwerk:
§ VPN-Typ: L2TP-IPSec-VPN
§ Internetprotokoll (TCP/IP) anwählen – Button Eigenschaften anwählen
§ IP-Adresse automatisch beziehen
§ Folgende DNS-Serveradressen verwenden: bei mir der Domaincontroller, welcher auch den RSA ACE-Server stellt
o Erweitert:
§ Zu Testzwecken sollte die Windows-Firewall deaktiviert werden
· Eigenschaften übernehmen und speichern – Fertig

WICHTIG!!! Auf dem Server, der den RSA ACE/Agent enthält die Systemsteuerung öffnen und den RSA ACE/Agent anwählen. Unter der Registerkarte Remote folgende Einstellungen vornehmen:
· Send domain with username to RSA ACE/Server deaktivieren
· Routing and Remote Access will use RSA EAP aktivieren
Das Node Secret:
Das Node Secret ist ein symmetrischer Schlüssel, welcher nur dem ACE Agent und dem ACE Server bekannt ist. Dies können zwei unterschiedliche Rechner sein, oder wie in meinem Fall ein und der Selbe. Beide Rechner nutzen diesen Schlüssel um Datenpakete verschlüsselt über das Netzwerk auszutauschen. Um ein Node Secret zu erzeugen muss ein Benutzer (i.d.R. der Admin.) unter Start – Programme – RSA/ACE Agent – Authentication Test eine Testauthentifizierung vornehmen. Nach einer erfolgreichen Authentifizierung ist das Node Secret für ACE Agent und ACE Server erstellt. Sollte ein Fehler auftreten, kann dies auf dem ACE Server unter Start – Programme – RSA ACE Server – Log Monitor nachvollzogen werden. Das Node Secret wird in der Datenbank des ACE Servers abgelegt.

Häufige Fehlermeldungen:

In der Regel sind die häufigsten Fehlermeldungen in den von RSA mitgelieferten Dokumenten/Whitepapers WinAgentAdmin.pdf und ace_admin.pdf unter dem Lesezeichen Troubleshooting dokumentiert und erklärt. Jedoch sind einige der vorgeschlagenen Lösungsmethoden nicht geeignet oder tauchen gar nicht erst auf.

Node Verification failed: Ist ein Fehler, der mehrere Ursachen haben kann. Fest steht jedoch, dass Agent und Server nicht mehr mit einander kommunizieren können, da der symmetrische Schlüssel (das node secret) korrumpiert wurde. Am häufigsten tritt der Fehler auf, wenn der Haken Node Secret Created im Konfigurationsmenü des Agent Host entfernt wurde, oder der Agent Host gelöscht wurde, einen anderen Namen oder eine andere IP-Adresse erhalten hat.
Um den Fehler zu beheben folgendes tun:
· In der Systemsteuerung den RSA/ACE Agent öffnen und unter Advanced den Button Clear Node Secret anklicken
· Anschließend den Agent Host aus der Datenbank des ACE Servers anwählen. Start – Programme – RSA ACE Server Database Administration – Agent Host – Edit Agent Host... – Rechner wählen, auf dem der Agent läuft und den Haken löschen, der da lautet: Node Secret Created
Nun existiert kein Node Secret mehr. Unter Umständen jedoch befindet sich auf dem Rechner, der den RSA ACE/Agent beherbergt in der Windows Registratur noch das Node Secret. Dies ist dann der Fall, wenn das Löschen über den Button Clear Node Secret des RSA/ACE Agent aus irgendeinem unerfindlichen Grund fehlgeschlagen ist. Es muss also die Windows Registratur bearbeitet werden.
Start – Ausführen – regedit eingeben. Unter HKEY_LOCAL_MACHINE – SOFTWARE – SDTI – ACECLIENT befindet sich eine Datei mit dem Namen NodeSecret vom Typ REG_BINARY. Diese Datei enthält den symmetrischen Schlüssel, der für die verschlüsselte Kommunikation zwischen RSA ACE/Agent und RSA ACE/Server verwendet wird. Diese Datei also löschen. Anschließend muss wieder eine Testauthentifizierung durchgeführt werden, um ein neuen Node Secret zu erzeugen.

User not in Database oder User not on Agent Host:
Dies kann ebenfalls viele Gründe zur Ursache haben. Die nahe liegenden Gründe sind die, dass die Gruppe oder der User selbst auf dem Agent Host nicht aktiviert ist, bzw. nicht existiert. Was in den Whitepapers jedoch nicht erwähnt wird, ist die Tatsache, dass eine besondere Einstellung des RSA/ACE Agent in der Systemsteuerung des Rechners, welcher den Agent Host beherbergt auch zu dieser Fehlermeldung führen kann. Wenn der RSA Server in einer Windows Domäne hängt und die User über eine LDAP Synchronisation angesprochen werden, und diese User auf dem Agent Host aktiviert sind, werden die Benutzer mit ihrem Distinguished Name angesprochen. Das bedeutet, ein Benutzer mit dem Namen Fritz muss sich auch als solcher authentifizieren. Wird beispielsweise der Domänenname mit übergeben (hier einmal angenommen die Domäne heißt MyDomain.test), meldet sich der Benutzer Fitz folgendermaßen an: MyDomain/Fritz. Dieser User ist dem Agent Host jedoch so nicht bekannt.
In der Systemsteuerung den RSA/ACE Agent öffnen und darauf achten, dass unter der Registerkarte Remote folgender Haken nicht gesetzt ist: Send domain with username to RSA ACE/Server
Diese Einstellung bewirkt bei einer Aktivierung das eben geschilderte Szenario und führt zu den oben genannten Fehlermeldungen.

ICH HOFFE, dass ich dir etwas helfen konnte.
Gruß Basti

#4 wow, danke erstmal für die Anleitung; ich werde dies heute und morgen mal durchgehen und mich dann wieder melden, ob's geklappt hat oder noch andere Fragen auftauchen!

(Also etwas ist schon mal unklar: RSA selber hat mir gesagt, dass der Ace/Server NICHT auf einem DC installiert werden soll...aber ich versuche es trotzdem mal so...)

Gruss
Michel

#5 Mag sein, dass RSA den ganz Kram auf einem separaten Logon-Server haben möchte, aber ich habe in meiner Testdomäne nur einen Server zur Verfügung. Und der läuft als DC, VPN-Server und RSA/ACE-Server. Und bisher habe ich keine Probleme.

Viel Glück beim Einrichten.

PS: Ich finde es merkwürdig, wie die Marktführer sein können. Bei diesen Implemenation Guides kann man genausogut ein Buch rückwärtz lesen. Ich habe alles über TRY und ERROR rausgefunden.

#6 Die Anleitung ist wirklich fast unbrauchbar. Als normalsterblicher Admin ist es meiner Meinung nach nicht möglich, dies mit vernünftigem Aufwand zu installieren.

Ich habe es nochmals versucht, mit dem Effekt, dass mein DC kein Login mehr entgegennimmt, obwohl ich nach der Agent-Installation die nötigen Einstellungen vor dem Neustart gemacht habe. Nun habe ich mit dem RSA Lieferanten Kontakt aufgenommen, aber wieder einmal ist kein RSA Supporter erreichbar und der eine, den ich am Telefon hatte, kannte nicht mal den Unterschied zwischen Memberserver und DC, und die einen sagen da, DC Installation von RSA Server ist kein Problem, ander behaupten das Gegenteil, ich krieg noch Anfälle...

Wenn sich heute keiner meldet bei mir, werd ich den ganzen Sch... wieder zurückschicken.

Im Internet ist ja auch nichts zur Installation zu finden, ausser die unbrauchbaren RSA Dokus. Das Board hier ist das einzig brauchbare, aber das Produkt halt nicht.

Vielleicht bin ich halt einfach zu doof für RSA :-/

Auf jeden Fall nochmals danke für Deine Hilfe, ich melde mich wieder sobald ich mehr weiss!

Gruss
Michel

#7 Ja, die Dokus sind echt der Hammer. Ich habe auch ewig dran rumgefriemelt. Ich hatte es auch mit VPN getestet. Bei mir war der Haken, daß der Server auf UTC Zeit gestellt werden mußte, dann ging es.
Insgesamt ist es ziemlich verwirrend.
Man hat zum einen die normale Konsole (kA wie das genau hieß) und dann noch mal in der Systemsteuerung etc.
ziemliches Durcheinander. Aber bei mir lag es echt an der Zeiteinstellung. Zuerst muß man natürlich die Authentifizierung lokal auf dem DC testen...
__________
Woher soll ich wissen was ich denke, bevor ich höre was ich sage??
Sag NEIN zu HD+/CI+ - boykottiert die Etablierung von HD+/CI+!

#8 Wo stelle ich denn das ein? Habe bei der RSA/Server Einstellung unter Systemsteuerung nichts gefunden?

Auf jeden Fall habe ich heute beim Lieferanten um Support gebeten, da war natürlich niemand da...bei RSA selber habe ich auch angerufen und ein Techniker sollte sich bei mir melden.

Ist aber nicht geschehen...

Ich hoffe, morgen klappt das. Dann will ich mal mit so einem Typen am Telefon gleich die Installation schrittweise durchführen. Wenn's klappt, werde ich das hier posten!

Gruss

#9 nicht am RSA Server macht man das, ich hatte das in den Windows Systemeinstellungen am RSA Server gemacht. Erst danach ging es.

UTC ist glaub ich GMT-1. Ist natürlich für einen DC der vielleicht auch TinmeServer oder Exchange ist übel.
Im 2. Versuch hatte ich das Ganze dann auf einer separaten Kiste.

Aber anfangs hatte ich es wie nuubian auf einer Kiste die DC, VPN und RSA Server war. Da meine Tokens abgelaufen sind kann ich es aber auch nicht noch einmal aufbauen..
__________
Woher soll ich wissen was ich denke, bevor ich höre was ich sage??
Sag NEIN zu HD+/CI+ - boykottiert die Etablierung von HD+/CI+!

#10 Hallo MIB 76,

also ich denke, dass es weniger an der Serverzeit liegt. Die kann man ja locker umstellen. Außerdem wird bei der ersten Resynchronisation der Token mit der Serveruhr ein OFFSET gespeichert, welches der Server bei der Authentisierung berücksichtigt.

Ich würde mal behaupten, dass du doche einen Server laufen hast, über den du im AD auch die Gruppen der Computer (Memberserver und Benutzer) drin hast. Auf dem Server sollte meiner Meinung nach der RSA/ACE Server laufen.

Ich denke du besitzt eine CD/DVD mit der Aufschrift Authentication Agent. Bie der Installation sind meiner nach folgende Komponenten auf dem DC und Memberservern zu installieren:

Domain Controller: Für ein Domänen Logon: Domain Authentication Server
Clients und Memberserver: Domain Authentication Client
für ein Offline Logon (Computer hängt grad nicht an Domäne): zusätzlich Lokal Authentication Client

User die Token zuweisen (Über die Datenbank Administration) Token resynchronisieren.

Unter Agent Hosts den Server angeben, der den Domain Authentication Server
installiert hat.

Eine Authentifizierung läuft so ab, dass der Agent Host den Passcode und Benutzernamen entgegennimmt und an den ACE Server weiterleitet, dieser entscheidet anschließend, ob eine Verbindung zugelassen wird oder nicht, leitet diese Information an den Agent Host weiter, welcher wiederum dem Client mitteilt, ob der Zugriff gewährt oder verweigert wurde. D
er Agent Host und RSA/ACE Server können ruhig auf einer Maschine installiert werden, das geht gut und bereitet dem System keine Probleme.

Damit sind der Agent Host und der RSA/ACE Server auf dem DC installiert. Und haben logischer Weise alle die selbe IP-Adresse.

Also auch wenn es komisch klingt, auf dem Server, wo auch der RSA/ACE Server installiert ist, muss über die Datenbank Administration unter Agent Host noch der Name des DC's eingegeben werden, die IP findet er dann automatisch.

* Der Agent Host ist für Windows in der Regel ein NET OS Agent

* Die AKtivierung des Kästchen Enable Windows Password Integration sorgt dafür, dass ein Benutzer nach der Authentifizierung mit einem SecureID Token noch zusätzlich Windows Anmeldedaten eingeben muss. (willste bestimmt aber nicht so haben)

* Über die Group Activations… und User Activations… können Benutzer und Gruppen von Benutzern angegeben werden, die sich authentifizieren können sollen

* Das Node Secret sollte noch nicht erstellt ein. Wenn Doch mache folgendes auf dem DC wo der RSA/ACE-Server installiert ist:

1. In der Systemsteuerung auf dem DC den RSA/ACE Agent öffnen und unter Advanced den Button Clear Node Secret anklicken

2. nimm den Haken aus dem Kästchen Node Secret Created (wir befinden uns noch immer bei der Konfiguration des Agent Host)

3. Start – Ausführen – regedit eingeben. Unter HKEY_LOCAL_MACHINE – SOFTWARE – SDTI – ACECLIENT befindet sich u.U. noch eine Datei mit dem Namen NodeSecret vom Typ REG_BINARY. Diese Datei löschen

4. Jetzt ist das Node Secret Getötet.

5. Neues Node Secret wie folgt erzeugen: unter Start – Programme – RSA/ACE Agent – Authentication Test eine Testauthentifizierung vornehmen. Nach einer erfolgreichen Authentifizierung ist das Node Secret für ACE Agent und ACE Server erstellt.

6. Prüfen, ob der Haken Node Secret Created jetz beim Agent Host wieder gesetzt ist

Ich habe, wie gesagt keine Domänenauthentifizierung implementiert und habs auch noch nie gemacht. Aber die meisten Fehler sind die, das keiner versteht, was denn der Agent Host ein soll. Also der Aget Host ist so zu sagen nur ein Türsteher, der zwischen Client und Server vermittelt. Er kan auf einem eigenen Server laufen (sicherer), oder aber auch direkt auf dem Server (RSA/ACE Server auf dem DC), das macht kein Problem.

Benutzer, die sich dann am System anmelden wollen nutzen den Domain Authentication Client. Der Kümmert sich dann denke ich um alles, das läuft dann über die MS GINA (Microsoft Graphical Identification and Authentication dynamic-link library (DLL)

Du must also deine Memberserver NICHT unter Agent Host hinzufügen! Ich hoffe jetzt sind die Dinge klarer.

Gruß Basti
[/b]

#11 Ich fasse es nicht - ICH FASSE ES NICHT!

Ein Forum - UND NOCH DAZU AUF DEUTSCH - in dem man offen über RSA konfiguration reden kann! Ansonsten gehts ja in Foren meist um Themen wie "hilfe ich kann mein wlan router nicht pingen" oder "hilfe, mein xp rechner ist so komisch seit ich ohne firewall ins internet gehe".

Erstmal - Basti, ich finde es einfach grandios, wie du hier anderen leidtragenden der menschenverachtenden Doku-Kultur von RSA mit deiner Erfahrung hilfst. Ich mache das selbe in anderen Themenbereichn auch sehr detailiert in anderen Foren, da es einfach schön ist, wenn EINER eine Sache Löst, und VIELE davon profitieren, indem man der Welt eine verständige Step-by-Step Anleitung schreibt.
Viele halbgare Forenbeiträge in diversen Foren helfen nicht wirklich. So eine richtige Anleitung wie du sie hier anbietest ist schon wirklich klasse.

Um nochwas über die "RSA Anleitung" zu meckern - unter ALLER SAU.
Das rafft man nur als Professor mit IQ 180 fürchte ich.

Nun zu meinem (bescheidenen) Problem...

Ich habe einen ACE. Dieser dient zur Authentifizierung von VPN Usern. Als Agent Host (NAS) ist ein Cisco VPN Concentrator im Einsatz. Läuft seit Jahren wunderbar. Wird von mir nicht administriert. ;-). Daher hab ich auch nicht viel Plan davon.
Was ich jedoch brauche:
Ich möchte, dass bei RAdius-Anfragen von ANDEREN Agent Hosts, also NAS`s im Radius Accept-Paket ein spezielles Radius-Attribut mitgeliefert wird (session-timeout). Bei Anfragen die vom VPN Concentrator kommen soll dieses Attribut jedoch NICHT mitgeliefert werden. Comprende? Ich denke gelesen zu haben dass ich pro USER eine config machen kann (profile?) welche RAdius Attribute bei der Authentifizierung von bestimmten USERn gesendet werden sollen.
Also auf gut deutsch...

Wenn der VPN Concentrator den ACE kontaktiert >>> KEIN "session-timeout" Attribut.
Wenn ein anderer NAS den ACE kontaktiert >>> "session-timeout" im Accept-Paket mitsenden.

Kommt Jungs, macht mich glücklich ... besten Dank.
Dieses Forum ROCKT! ;-)

#12 @spacyfreak

puuh, da bin ich überfragt, weil ich die Lösung ohne Radius gemacht habe.
Vielleicht in der VPN-Richtlinie?
Was genau willst du erreichen?

#13 Nun, ich will ganz einfach erreichen, dass bei Radiusanfragen, die vom VPN Concentrator an den ACE Radius Server gesendet werden im Access-Accept Paket KEIN Attribut "Session-timeout" mitgesendet wird.

Wenn ein beliebiger ANDERER NAS den ACE Radius-Server anfragt, SOLL aber das Attribut "Session-Timeout" mitgeliefert werden.

Die ganzen Zusammenhänge wiso das so sein soll zu erklären würde wahrscheinlich ein halbes Lexikon füllen.

Laut ACE Hilfe kann man mit Profilen den USERN oder Gruppen von Usern Radius-Attribute mitsenden. D.h. wenn User Karl.Müller authentifiziert werden soll, wird ein definierbares Radius-Attribut mitgesendet (z.B. welchen Service-Type der User nutzen darf oder ähnliches).

Ich will aber nicht dass nach Usern differenziert wird, sondern nach ANFRAGENDEN NAS` soll entschieden werden, OB das Radius-Attribut mitgesendet wird, oder nicht.

Ja, es ist abstrakt. Ja, die IT ist eine verückte Welt.

#14 Hi,

ich bin mir nicht sicher, ob das überhaupt so geht...
Jedenfalls hört es sich ja für mich so an, daß das evtl. eine Einstellung am VPN Concentrator sein könnte?

Zitat

vom VPN Concentrator an den ACE Radius Server gesendet werden im Access-Accept Paket KEIN Attribut "Session-timeout" mitgesendet wird.

Wenn ich mich an meine VPN Versuche erinnere, dann ist das doch immer eine clientseitige Einstellung..
__________
Woher soll ich wissen was ich denke, bevor ich höre was ich sage??
Sag NEIN zu HD+/CI+ - boykottiert die Etablierung von HD+/CI+!

#15

Zitat

HeVTiG postete
Hi,

ich bin mir nicht sicher, ob das überhaupt so geht...
..

Es funktioniert schon so.

Der VPN Concentrator stellt ja eine Anfrage an den ACE Server
(Radius Access-Reply Paket)
In diesem Anfragepaket ist verschlüsselt Username, Pin+Token u. weiters.
Der ACE Server prüft dann ob PIN/Token stimmen und sendet wenn erfolgreich eine "Accept" Antwort.
(Radius Access-Accept Paket).
In dieser Antwort können noch diverse Radius-Attribute mitgesendet werden.
Zum Beispiel "Idle Time Out" oder "Session-Timeout". Also wie lange die Freischaltung gültig sein soll.

Dieses Attribut Session-Timout will ich aber NICHT zum VPN Concentrator gesendet haben. Ich habe noch andere Geräte, die per Radius User authentifizieren sollen. Da geht es dann nicht um VPN, sondern eben andere Ressourcen, für die ich den ACE nutzen will um die User zu berechtigen.

Der ACE soll also auf Anfragen von verschiedenen Geräten auf verschiedene Weise reagieren - eben entsprechende Radius-Attribute senden. Wie dies zu konfigurieren ist, das ist die Frage.

Ich kann es konfigurieren, dass IMMER ein best. Attribut mitgesendet wird, egal welcher NAS die Anfrage gestellt hat. Aber es soll ja nicht IMMER gesendet werden, sondern nur wenn BESTIMMTE NAS Geräte die Anfrage stellen.