Kerberos: Single Sign On für BS2000

Transkript

1 Kerberos: Single Sign On für BS2000 Ausgabe April 2011 Seiten 7 Überblick Ein Single-Sign-On-System (SSO-System) ist ein System zur automatischen und komfortablen, weil einmaligen, Anmeldung an verschiedene Ressourcen in heterogenen Netzwerken. Es automatisiert nach einer einmaligen Identifikation und Authentifikation den Zugang zu allen weiteren Anwendungen des Benutzers im Netz ein SSO- System ist also quasi der Generalschlüssel, der aus Benutzer-Sicht Zugang zu allen von ihm benötigten Anwendungen verschafft, soweit er Zugangsrechte besitzt. Kerberos ist ein standardisiertes, auf vielen Plattformen übliches Netzwerk-Authentisierungsprotokoll. Im BS2000/OSD unterstützt SECOS das Single-Sign-On-Verfahren mit Kerberos ab Version V5.0. Inhalt Überblick 1 Nutzen von Single-Sign-On 2 Kerberos-Konzept 2 Kerberos-Principal 2 Voraussetzungen für den Einsatz von Kerberos 2 Verwaltung der Schlüssel in der Key-Tabelle des BS2000/OSD-Host 3 BS2000/OSD-Komponente SECOS-KRB 3 Kerberos-Authentisierung beim Zugang zu Anwendungen in BS2000/OSD 3 Kerberos-Authentisierung beim Aufbau einer Verbindung zu $DIALOG 3 Kerberos-Authentisierung beim Aufbau einer Verbindung zu OMNIS-MENU 3 Kerberos-Authentisierung beim Aufbau einer Verbindung zu openutm 3 4

2 Description Paper Ausgabe: April 2011 Kerberos: Single Sign On für BS2000 Seite 2 / 7 Nutzen von Single-Sign-On In modernen komplexen Arbeitsumgebungen benötigen Benutzer häufig Zugriff auf mehrere Anwendungen, die sich zudem auf unterschiedlichen Servern/Systemen befinden können. Dazu müssen sie oft verschiedene Kennungen und Kennwörter benutzen. Unterschiedliche Anwendungen legen möglicherweise auch unterschiedliche Regeln fest, denen die Kennwörter entsprechen müssen. Außerdem ist es häufig erforderlich, unterschiedliche Kennwörter in verschiedenen Intervallen zu ändern. All dies bedeutet einen erhöhten Verwaltungsaufwand. Dieser fällt nicht nur bei den Benutzern an, sondern auch bei der Benutzerverwaltung, die vergessene Kennwörter zurücksetzen und wegen abgelaufener Kennwörter gesperrte Kennungen freigeben muss. Dieser erhöhte Verwaltungsaufwand kann durch den Einsatz eines Single-Sign-On-Systems (SSO-System) vermieden werden. Ein SSO-System ist ein System zur automatischen und komfortablen Anmeldung an Netzressourcen in heterogenen Netzwerken. Nach einer einmaligen Identifikation und Authentifikation auch mit Hilfe einer Chipkarte erübrigt ein SSO- System alle weitere Anmeldungen des Benutzers im Netz. Kerberos-Konzept Kerberos ist ein standardisiertes Netzwerk-Authentisierungsprotokoll, das am Massachusetts Institute of Technology (MIT) entwickelt wurde. Es handelt sich um ein Sicherheitssystem, das auf kryptographischen Verfahren basiert. Bei einer Authentisierung mit Kerberos werden keine Kennwörter oder andere vertraulichen Daten im Klartext über das Netzwerk gesendet. Das Abfangen von Kennwörtern im Netzwerk wird so verhindert. Die aktuelle Version von Kerberos (V5) ist in RFC1510 (RFC=Request for Comments) standardisiert. Die Standards selber sind definiert durch die Internet Engineering Task Force (IETF) und die Internet Engineering Steering Group (IESG). Umfassende Informationen zu den RFCs sind auf der Homepage der IETF zu finden: Kerberos arbeitet mit symmetrischer Verschlüsselung, d.h. alle Schlüssel liegen an zwei Stellen vor, beim Eigentümer eines Schlüssels (Principal) und beim KDC (Key Distribution Center). Ein Schlüssel wird vom Kennwort eines Principals abgeleitet. Kerberos-Principal Der Kerberos-Principal hat einen eindeutigen Namen, der aus beliebig vielen Komponenten bestehen kann. SECOS unterstützt maximal 1800 Bytes für den Principal-Namen. Jede Komponente ist durch den Komponenten-Separator /' voneinander getrennt. Die letzte Komponente ist der Realm, der von den übrigen Komponenten durch den getrennt ist. Der Name des Principal einer Anwendung ist üblicherweise aus drei Komponenten aufgebaut: Anwendung, Instanz und Realm. Das Format eines typischen Kerberos-V5-Principal-Namens ist: Anwendung/Instanz@REALM mit Anwendung Instanz REALM host für die Anwendung $DIALOG oder der Name der Anwendung Name des Servers, auf dem die Anwendung läuft, gemäß Domain Name Service (DNS) Name der Kerberos-Domäne, per Konvention in Großbuchstaben dargestellt Ein für einen typischen Kerberos-Principal im BS2000/OSD erhalten Sie über die in der Fußnote zitierte Addresse. In BS2000/OSD muss der Name des Principal mit dem SECOS-Kommando /ADD-KEYTAB-ENTRY in die Key-Tabelle aufgenommen werden. Der Administrator des Windows Domain Controller muss einen Service Account für den Client einrichten (siehe dazu auch das auf Seite 4). Voraussetzungen für den Einsatz von Kerberos KDC Es wird ein bestehendes KDC vorausgesetzt, z.b. der Domain Controller (PDC) von Windows 2000, der diese Funktionalität unterstützt. Client Wird am Client-PC über eine Terminal-Emulation eine Verbindungsanforderung zu BS2000/OSD gestellt, so ist es Aufgabe der Terminal-Emulation, sich ein gültiges Ticket zu besorgen und dieses dann an das BS2000/OSD-System weiterzureichen. Die Client-Betriebssysteme müssen kerberos-fähig sein: Windows-Systeme bieten die Kerberos-Unterstützung standardmäßig ab Windows 2000 (also auch bei Windows XP und Windows Server 2003) in den SSPI-Bibliotheken. Die SSPI-Aufrufe sind bereits ab Windows 95 möglich. Für UNIX-Systeme stehen GSSAPI-Bibliotheken frei zur Verfügung, zudem sind sie in manche Betriebssysteme (zum e Solaris ab Sun OS 5.8) integriert. Die C-Bindings von GSSAPI sind standardisiert (RFC 2744). Die Terminal-Emulation muss die Authentisierung mit Kerberos unterstützen. Wenden Sie sich bitte diesbezüglich an den Hersteller Ihrer Terminal-Emulation. Server Der Server (hier BS2000/OSD) muss erkennen, dass die Verbindung kerberos-fähig ist. Dazu muss sich der Client (z.b. die Terminal-Emulation) beim Verbindungsaufbau als DSS9763 (Device Type X 4F ) anmelden.

3 Description Paper Ausgabe: April 2011 Kerberos: Single Sign On für BS2000 Seite 3 / 7 Verwaltung der Schlüssel in der Key-Tabelle des BS2000/OSD-Host Die geheimen Schlüssel auf dem BS2000/OSD-Host werden in der Key-Tabelle verwaltet. Ein Eintrag in der Key-Tabelle besteht aus dem Kerberos-Namen des BS2000/OSD-Servers, wie er im KDC (Key Distribution Center) eingetragen ist, und mehreren Schlüsseln, die über kryptographische Verfahren aus dem angegebenen Kennwort für die Stellvertreterkennung und dem Servernamen abgeleitet werden. Das Kennwort selbst wird nicht gespeichert. Folgende Kommandos verwalten die Key-Tabelle: /ADD-KEYTAB-ENTRY /MODIFY-KEYTAB-ENTRY /REMOVE-KEYTAB-ENTRY /SHOW-KEYTAB-ENTRY BS2000/OSD-Komponente SECOS-KRB Die SECOS-Komponente SECOS-KRB enthält die Schnittstelle zur Abwicklung der Kerberos-Authentisierung im BS2000/OSD. Kerberos-Authentisierung beim Zugang zu Anwendungen in BS2000/OSD Folgende Komponenten unterstützen bei der Zugangskontrolle die Kerberos-Authentisierung: Zugang zu $DIALOG (ab SECOS V5.0) Zugang zu OMNIS/OMNIS-MENU (ab OMNIS V8.4 / OMNIS-MENU V3.4) Zugang zu openutm (ab openutm V5.3A) Kerberos-Authentisierung beim Aufbau einer Verbindung zu $DIALOG Kommandos zum Zugangsschutz Die Kommandos zur Vereinbarung des Zugangsschutzes für eine Kennung wurden in der Zugangsklasse NET-DIALOG- ACCESS um die Kerberos-Principals erweitert. Damit kann festgelegt werden, welchen Principals der Zugang zu dieser Kennung erlaubt ist, und ob zur Gewährung des Zugangs zusätzlich ein Kennwort erforderlich ist. Die betroffenen Kommandos sind: /SET-LOGON-PROTECTION /MODIFY-LOGON-PROTECTION /SHOW-LOGON-PROTECTION Ablauf einer Authentisierung beim Aufbau einer Verbindung zu $DIALOG Der Benutzer an einer Terminal-Emulation öffnet den BS2000-Dialog wie gewohnt. Das BS2000/OSD schickt eine LOGON-Aufforderung an die Emulation. Der Benutzer gibt das Kommando /SET-LOGON-PARAMETERS mit Jobname, Benutzerkennung, Abrechnungsnummer und gegebenenfalls weiteren Operanden, jedoch ohne Kennwort, ein. Für den Benutzer unsichtbar laufen daraufhin folgende Aktionen ab: Das BS2000/OSD schickt eine Ticket-Anforderung an die Terminal-Emulation. Diese besorgt sich ein Ticket vom Key Distribution Center und schickt es an das BS2000/OSD. Dort wird das Ticket entschlüsselt und validiert. Schließlich wird im BS2000/OSD geprüft, ob der als Kerberos-Principal identifizierte Besitzer des Tickets Zugriff auf die im Kommando /SET-LOGON-PARAMETERS angegebene Benutzerkennung hat. Abhängig vom Ergebnis dieser Prüfung wird der Zugang gewährt oder abgelehnt. Das Ergebnis der Authentisierung wird in BS2000/OSD in einem SAT-Record (SAT=Security Audit Trail) abgelegt. Bei Einsatz des Produkts JV (BS2000/OSD) ab V14.0A enthält die System-Jobvariable $SYSJV.PRINCIPAL den Namen des Principal. Kerberos-Authentisierung beim Aufbau einer Verbindung zu OMNIS-MENU OMNISKD-Anweisung Die Anweisung zur Vereinbarung des Zugangsschutzes für OMNIS-MENU-Benutzer wurde um die Angabemöglichkeit eines Kerberos-Principals erweitert. Damit kann festgelegt werden, welchen Principals die Arbeit mit OMNIS-MENU erlaubt ist, und ob zur Gewährung der Erlaubnis zusätzlich ein Kennwort erforderlich ist. Die betroffene Anweisung ist: DECLARE-USER Kerberos-Authentisierung beim Aufbau einer Verbindung zu openutm KDCDEF-Steueranweisung Die KDCDEF-Anweisung zur Vereinbarung des Zugangsschutzes für UTM-Benutzer wurde um die Angabemöglichkeit eines Kerberos-Principals erweitert. Damit kann festgelegt werden, welchen Principals die Arbeit mit einer UTM-Applikation erlaubt ist, und ob zur Gewährung der Erlaubnis zusätzlich ein Kennwort erforderlich ist. Die betroffenen Steueranweisungen sind: DEFAULT LTERM MAX USER

4 Description Paper Ausgabe: April 2011 Kerberos: Single Sign On für BS2000 Seite 4 / 7 KDCS-Aufrufe Damit die Vereinbarung des Zugangsschutzes für UTM-Benutzer nicht nur direkt in UTM, sondern auch in UTM- Teilprogrammen festgelegt werden kann, wurde KDCS um die Anzeigemöglichkeit von Kerberos-Principals erweitert. Damit kann in UTM-Teilprogrammen festgelegt werden, welchen Principals die Arbeit mit einer UTM-Applikation erlaubt ist. Die betroffenen Aufrufe sind: INIT INFO Eine BS2000/OSD-Benutzerkennung soll in ein Single-Sign-On-Verfahren auf Basis einer Windows-Domänenkennung eingebunden werden, so dass ein an Windows angemeldeter Benutzer beim Kommando /SET-LOGON-PARAMETERS kein Passwort mehr angeben muss. Für dieses gelten folgende Voraussetzungen für die Software-Konfiguration: Auf BS2000 BS2000/OSD-BC ab V6.0 SECOS ab V5.0 Windows-Server (Domain-Controller) ab Windows 2000, Windows-Clients (PCs der BS2000-Nutzer) ab Windows XP Terminal-Emulation mit Unterstützung des Terminal-Protokolls für Kerberos im BS2000/OSD. Gehen Sie dazu im Windows Domain Controller und im BS2000/OSD wie folgt vor: Im Windows Domain Controller Stellvertreterkennung auf dem Domain Controller einrichten Für das BS2000/OSD-System müssen auf dem Domain Controller Kerberos-Schlüssel hinterlegt werden. Dazu wird eine Stellvertreterkennung auf dem Domain-Controller eingerichtet: Starten Sie das Active Directory Management Tool. Klicken Sie mit der rechten Maustaste auf den Ordner Benutzer und wählen Sie die Funktion Neu: Benutzer aus. Tragen Sie den Namen der Benutzerkennung ein. Speichern Sie die Benutzerkennung. Der Name der Benutzerkennung ist frei wählbar. Es ist sinnvoll, einen Namen zu wählen, der auf die Verwendung als Platzhalter für ein BS2000/OSD-System hinweist. Im Domain Controller den Kerberos-Namen für das BS2000/OSD-System zuweisen Der Stellvertreterkennung wird per Account Mapping zusätzlich der Name eines BS2000/OSD-Servers in Kerberos-Notation zugewiesen. Geben Sie folgendes Kommondo im DOS-Fenster an: ktpass -princ host/hostname@ -mapuser account -pass password -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL out keytab-entry hostname account DNS-Name des BS2000/OSD-Systems DNS-Name der Active-Directory-Domäne. Dieser Name ist ein fester Wert für jede Active- Directory-Domäne. Stellvertreterkennung RC4-HMAC-NT Verschlüsselungsalgorithmus ( ab Windows Server 2003) password Kennwort für die Stellvertreterkennung (max.127 Zeichen) KRB5_NT_PRINCIPAL Kerberos Principal (ab Windows Server 2003) keytab-entry Ausgabedatei für Keytab-Eintrag Hinweise Das Kommando ktpass ist in der englischen Microsoft Knowledge Base beschrieben. Sie finden die Beschreibung im Internet unter Klicken Sie auf Knowledge Base Suche und füllen Sie das Formular folgendermaßen aus: Englische Knowledge Base Suchbegriff: ktpass Art der Suche: Nur Titel

5 Description Paper Ausgabe: April 2011 Kerberos: Single Sign On für BS2000 Seite 5 / 7 Das gleiche Kennwort für die Stellvertreterkennung muss im nächsten Schritt auch im BS2000/OSD angegeben werden. Verwenden Sie auf jeden Fall ein gutes, das heißt nicht erratbares Kennwort. Wer dieses Kennwort kennt und über Programmiererfahrung verfügt, kann sich auch bei Einsatz von Kerberos dem BS2000/OSD gegenüber nach Belieben identifizieren. Windows und BS2000/OSD verwenden unterschiedliche Zeichenkodierung (ASCII bzw. EBCDIC). Außerdem können auf beiden Systemen länderspezifische Zeichensatzvarianten installiert sein. Verwenden Sie deshalb nur Zeichen aus dem Internationalen Zeichensatz, also keine Umlaute. Nehmen Sie lieber ein etwas längeres Kennwort, um das Erraten zu erschweren, z. B. ktpass -princ host/d016ze04.mch.ts.fujitsu.net@ts.fujitsu.net -mapuser d016ze04 -pass liebereinbisschenlaenger -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out keytab-entry Ab Windows Server 2003 sollte der Verschlüsselungstyp RC4-HMAC-NT verwendet werden, um die Interoperabilität mit allen beteiligten Systemen zu gewährleisten. Ab Windows Server 2003 versendet das KDC die Tickets mit einer Key Version Number (KVNO). Es muss sichergestellt werden, dass die entsprechende KVNO auch im BS2000/OSD eingetragen wird. Beachten Sie dazu die entsprechende Ausgabe des ktpass Kommandos. Successfully mapped host/d016ze04.mch.ts.fujitsu.net to d016ze04. Key created. Output keytab to keytab-entry: Keytab version: 0x502 keysize 46 host/d016ze04.mch.ts.fujitsu.net@ts.fujitsu.net ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x17 (RC4-HMAC) Im BS2000/OSD Kerberos-Schlüssel im BS2000/OSD einrichten Die Verwaltung der Kerberos-Schlüssel im BS2000/OSD unterliegt dem Sicherheitsbeauftragten (standardmäßig die Benutzerkennung SYSPRIV). Das Kommando dazu lautet: /ADD-KEYTAB-ENTRY *STD('host/hostname@' - /,KEY = *PASSWORD('password',KEY-VERSION='key version number') Für hostname,, password und key version number müssen dieselben Werte angegeben werden wie im Domain Controller. Bitte beachten Sie, dass speziell per Konvention in Großbuchstaben angegeben werden muss. /ADD-KEYTAB-ENTRY *STD('host/d016ze04.mch.ts.fujitsu.net@TS.FUJITSU.NET' - /,KEY = *PASSWORD('liebereinbisschenlaenger',KEY-VERSION=3) Ab SECOS V5.3 steht alternativ das SDF-Kommando CONVERT-KEYTAB zur Verfügung mit dessen Hilfe das Einrichten des Kerberos-Schlüssels im BS2000/OSD vereinfacht wird. CONVERT-KEYTAB unterstützt bei Verfügbarkeit von openft und entsprechender TRANSFER-ADMISSION die Übertragung der Ausgabedatei für den Keytab-Eintrag (im obigen keytab-entry ) vom Domain Controller zum BS2000/OSD und die automatische Umsetzung in entsprechende Kommandos zum Eintragen des Schlüssels im BS2000/OSD. /CONVERT-KEYTAB TRANSFER-ADMISSION=getktpass,PARTNER=DOMAINCTL Die von CONVERT-KEYTAB erzeugte Kommandodatei CONVKTAB.JCL muss dann unter der Kennung des Sicherheitsbeauftragten zum Ablauf gebracht werden. Hierfür ist es erforderlich, dass die Kennung des Sicherheitsbeauftragten das Privileg STD-PROCESSING besitzt.

6 Description Paper Ausgabe: April 2011 Kerberos: Single Sign On für BS2000 Seite 6 / 7 Benutzerkennung für Windows-Domänenkennung freischalten Als letzter Schritt wird für eine BS2000/OSD-Benutzerkennung festgelegt, welche Windows-Kennungen zugriffsberechtigt sind. Für den Single-Sign-On -Gedanken ist es dabei sinnvoll, auf die Prüfung des BS2000/OSD-spezifischen Kennworts zu verzichten. Das Kommando, das der Benutzerverwalter eingeben muss, lautet: /MODIFY-LOGON-PROTECTION userid - /,NET-DIALOG-ACCESS=*YES - / (PASSWORD-CHECK=*NO - /,ADD-PRINCIPAL='windowsaccount@' - / ) userid windowsaccount BS2000/OSD-Benutzerkennung, für die Single Sign On mit Kerberos eingeführt werden soll. Domänen-Kennung des Benutzers, der Zugriff auf die BS2000/OSD-Benutzerkennung erhalten soll. DNS-Name der Active-Directory-Domäne, wie schon beim Einrichten des Schlüssels vergeben. /MODIFY-LOGON-PROTECTION TSOS - /,NET-DIALOG-ACCESS=*YES - / (PASSWORD-CHECK=*NO,ADD-PRINCIPAL='MCHHMUSTERMANN@TS.FUJITSU.NET') Hinweise Für eine BS2000/OSD-Benutzerkennung können auch mehrere Windows-Accounts zugriffsberechtigt sein. Die Windows-Benutzerkennung und der werden als Wildcard-Strings interpretiert. Principal die Arbeit mit OMNIS-MENU erlauben Ebenso wie beim Zugang zu BS2000-Benutzerkennungen kann ein Principal auch zur Arbeit mit OMNIS-MENU berechtigt werden. Die OMNISKD-Anweisung, die der OMNIS-MENU-Verwalter verwenden muss, lautet: DECLARE-USER =userid, - PRINCIPAL='windowsaccount@', - userid windowsaccount OMNIS-MENU-Kennung, für die Single Sign On mit Kerberos eingeführt werden soll. Domänen-Kennung des Benutzers, der Zugriff auf die BS2000/OSD-Benutzerkennung erhalten soll. DNS-Name der Active-Directory-Domäne, wie schon beim Einrichten des Schlüssels vergeben. DECLARE-USER ==HMUSTERMANN, - PRINCIPAL='MCHHMUSTERMANN@TS.FUJITSU.NET', - Principal den Zugang zu einer UTM-Applikation unter Kontrolle von openutm erlauben Ebenso wie beim Zugang zu BS2000-Benutzerkennungen kann ein Principal auch zur Arbeit mit einer UTM-Applikation berechtigt werden. Wenn die Zugangskontrolle in openutm durchgeführt werden soll, muss der UTM-Verwalter folgende KDCDEF-Steueranweisung verwendent: USER userid, - PRINCIPAL='windowsaccount@', - Userid windowsaccount UTM-Benutzerkennung, für die Single Sign On mit Kerberos eingeführt werden soll. Domänen-Kennung des Benutzers, der Zugriff auf die BS2000/OSD-Benutzerkennung erhalten soll. DNS-Name der Active-Directory-Domäne, wie schon beim Einrichten des Schlüssels vergeben.

7 Description Paper Ausgabe: April 2011 Kerberos: Single Sign On für BS2000 Seite 7 / 7 USER HMUSTERMANN, - PRINCIPAL='MCHHMUSTERMANN@TS.FUJITSU.NET', - Soll die Zugangskontrolle dagegen in einem entsprechenden UTM-Teilprogramm durchgeführt werden, muss der UTM- Verwalter über die entsprechenden KDCDEF-Steueranweisungen dafür sorgen, dass bei der Kommunikation eines Clients mit einem LTERM bzw. TPOOL ein Kerberos-Dialog durchgeführt wird, z.b.: LTERM ltermname, - KERBEROS-DIALOG=YES, - ltermname Name eines LTERM-Partners, mit dem ein Kerberos-Dialog durchgeführt werden soll. LTERM LT , - KERBEROS-DIALOG=YES, - Um die Kerberos-Ticketinformationen in einem entsprechenden UTM-Teilprogramm verfügbar zu haben, muss im UTM- Teilprogramm folgender KDCS-Aufruf implementiert werden: INFO CD Alle Rechte vorbehalten, insbesondere gewerbliche Schutzrechte. Änderung von technischen Daten sowie Lieferbarkeit vorbehalten. Haftung oder Garantie für Vollständigkeit, Aktualität und Richtigkeit der angegebenen Daten und Abbildungen ausgeschlossen. Wiedergegebene Bezeichnungen können Marken und/oder Urheberrechte sein, deren Benutzung durch Dritte für eigene Zwecke die Rechte der Inhaber verletzen kann. Weitere Einzelheiten unter ts.fujitsu.com/terms_of_use.html Herausgegeben durch: Andreas Ginzkey Telefon: andreas.ginzkey@ts.fujitsu.com de.ts.fujitsu.com Extranet extranet.de.ts.fujitsu.com Copyright Fujitsu Technology Solutions GmbH 2011