Wiki-Quellcode von RTH_DE_EN_Einmalanmeldung

Zeige letzte Bearbeiter
1 Da Kerberos und NTLM jetzt im Einmalanmeldemenü zusammen sind, muss diese Seite in deutsch und englisch neu erstellt werden. Der Inhalt der beiden alten Seiten befindet sich erstmal noch hier:
2
3 {{content/}}
4
5 {{figure image="single_sign_on_ntlm_de.png" width="600"}}
6 Nutzeroberfläche für die Einstellungen zu NTLM. Nur verfügbar, wenn die Lizens dies erlaubt.
7 {{/figure}}
8
9 NTLM wird für die Authentifizierung von Formularbenutzern verwendet. Ein typisches Einsatzszenario sind Formulare, die intern von Mitarbeitern eines Unternehmens aufgerufen werden. Über NTLM kann das Formular auf die Benutzerdaten des angemeldeten ActiveDirectory zugreifen.
10
11 {{info}}
12 NTLM ist nur verfügbar, wenn die Lizenz dies erlaubt.
13 {{/info}}
14
15 == NTLM nutzen ==
16
17 Mit diesem Schalter lässt sich die NTLM-Benutzerauthentifizierung für Formulare aktivieren bzw. deaktivieren
18
19 === Mit {{fserver/}} synchronisieren ===
20
21 Wenn dieser Schalter aktiviert ist, wird beim Speichern der Einstellungen die aktuelle Konfiguration auf alle (erreichbaren) {{fserver number="plurar"/}} übertragen.
22
23 === Domain-Controller Host ===
24
25 Host (FQN) des ActiveDirectory Controller für die NTLM-Authentifizierung eines Benutzers und die anschließende Ermittlung dessen Daten über LDAP.
26
27 {{code}}
28 Beispiel: domain.example.de
29 {{/code}}
30
31 == NTLM-Authentifizierung ==
32
33 Die folgenden Einstellungen sind für die Authentifizierung eines Benutzers mittels NTLM notwendig:
34
35 === Hostname des Domain-Controller Hosts ===
36
37 Hostname des Active-Directory-Controller.
38
39 {{code}}
40 Beispiel: domain
41 {{/code}}
42
43 === Windows-Domainname ===
44
45 Hier können je nach AD verschiedene Schreibweisen des Domainnamen verwendet werden.
46
47 {{code}}
48 Beispiel: example.de oder example0
49 {{/code}}
50
51 {{info}}
52 Hier muss der Domain-Name angegeben werden, zu denen die zu authentifizierenden Benutzerkonten gehören.
53 Dieser Domain-Name kann sich von der Domäne des Computer-Kontos unterscheiden (Dabei handelt es sich um den NetBIOS-Name des Computers und nicht den DNS-/FQDN-Name).
54
55 Der zu benutzende **Windows-Domainname** lässt sich beispielhaft ermitteln, indem man auf einen in der Domäne angemeldeten Client eine Windows Konsole öffnet (//Start / Ausführen / cmd//) und dort folgenden Befehl eingibt:
56 **echo %userdomain%**
57 {{/info}}
58
59 === Computerkonto ===
60
61 Dieses Computerkonto muss die Berechtigung zu Nutzerverifizierung haben. Hierbei darf es sich **nicht** um ein Active-Directory Nutzerkonto handeln!
62
63 {{info}}
64 Ein Computer-Account ist am '$'-Zeichen im Domain-Namen erkennbar. z.B. example$@domain.de
65 {{/info}}
66
67 Beschreibung für die Vorgehensweise zur Erzeugung eines Computer-Accounts im //Active Directory Server// (externer Link): [[Creating a Computer Account for NTLM Authentication>>url:https://wiki.ca.com/display/GATEWAY83/Creating+a+Computer+Account+for+NTLM+Authentication||rel="__blank" title="Creating a Computer Account for NTLM Authentication"]]
68
69 === Computerkontopasswort ===
70
71 Passwort des Computerkontos
72
73 == LDAP-Benutzersuche ==
74
75 Die folgenden Einstellungen sind für eine Nutzersuche nach erfolgter NTLM-Authentifizierung notwendig:
76
77 === Port ===
78
79 Der zu verwende Port für die Verbindung mit dem LDAP-Server zur Nutzersuche
80
81 === SSL-Verbindung ===
82
83 Ermöglich das Aktivierung der SSL-verschlüsselten Kommunikation mit dem LDAP-Server
84
85 === Verweis-Sprünge ===
86
87 Gibt die Anzahl der zu folgenden Verweis-Sprünge (Referrals) an. ein Wert von 0 deaktiviert das Folgen von Verweisen.
88
89 === Nutzerkonto (mit Domainangabe) ===
90
91 Konto für die Benutzersuche innerhalb des LDAP-Servers. Dieses Konto muss entsprechende Rechte für eine Nutzersuche besitzen.
92
93 {{code}}
94 Beispiel: ldap@example.de
95 {{/code}}
96
97 === Nutzerkontopasswort ===
98
99 Passwort des Nutzerkontos
100
101 === BaseDN für Suche ===
102
103 LDAP BaseDN unter der die zu authentifizierten Benutzer gesucht werden sollen.
104
105 {{code}}
106 Beispiel: ou="users", dc="example", dc="de"
107 {{/code}}
108
109
110
111
112 == Einstellungen für Kerberos Authentifizierung ==
113
114 {{figure image="single_sign_on_kerberos_de.png" width="600"}}
115 Nutzeroberfläche für die Einstellungen zu Kerberos. Nur verfügbar, wenn die Lizens dies erlaubt.
116 {{/figure}}
117
118 Kerberos wird für die Authentifizierung von Formularbenutzern verwendet. Ein typischen Einsatzszenario sind Formulare, die "intern" von Mitarbeitern eines Unternehmens aufgerufen werden. In einem nachgeordneten Schritt kann das Formular dann Benutzerdaten des angemeldeten Nutzers aus dem ActiveDirectory bereitstellen.
119
120 Kerberos muss als Lizenz-Option freigeschaltet sein!
121 Ist dies der Fall, können folgende Einstellungen bearbeitet werden:
122
123 === Kerberos nutzen ===
124
125 Mit diesem Schalter lässt sich die Kerberos-Benutzerauthentifizierung für Formulare aktivieren/deaktivieren
126
127 === Mit {{fserver/}} synchronisieren ===
128
129 Wenn dieser Schalter aktiviert ist, wird beim Speichern der Einstellungen die aktuelle Konfiguration auf alle (erreichbaren) {{fserver number="plural"/}} übertragen.
130
131 === Nutzername ===
132
133 Windows Domain Account, welcher für den Zugriff auf das Key Distribution Center (KDC) benötigt wird, um den nachfolgenden Authentifizierungsprozess einzuleiten.
134 In den meisten Fällen ist dies ein User-Account aus dem AD, welcher als Service-Account fungiert und nicht zur Anmeldung an einer Workstation gedacht ist. 
135
136 {{info}}
137 Es wird ein Nutzername mit Domainangabe (FQDN) benötigt, wenn in der **krb5.conf** Datei, unter dem Abschnitt //[libdefaults]//, kein **default_realm** definiert ist.
138 //Beispiel: user@EXCAMPLE.COM //
139 {{/info}}
140
141 === Passwort ===
142
143 Passwort des o.g. Service-Accounts
144
145 === Datei krb5.conf ===
146
147 Hier wird der Inhalt der **krb5.conf** Datei definiert, in welcher die Konfiguration für Kerberos festgelegt werden.
148 Unter anderem werden hier die vom System unterstützten Verschlüsselungsverfahren aufgeführt, sowie der aktuell zu verwendende Realm (Administrationsbereich) und deren Mapping zu einem KDC.
149
150 ==== Dateistruktur ====
151
152 Die zu verwendende Schreibweise innerhalb der Datei orientiert sich an Windows INI-Dateien, das heißt, einzelne Abschnitte werden mit
153 einen Abschnittsnamen (in eckigen Klammern) versehen. Jeder Abschnitt enthält keine oder mehrere Zuordnungen,
154 die in folgender Form definiert werden können:
155
156 {{code language="java" title=""}}
157 foo = bar
158 {{/code}}
159
160 oder
161
162 {{code language="java" title=""}}
163 foobar = {
164 foo = bar
165 some = input
166 }
167 {{/code}}
168
169 ==== Abschnittsnamen ====
170
171 * //[libdefaults]//: Enthält die Einstellungen die von der Kerberos V5-Bibliothek verwendet werden
172 * //[realms]//: Realm-spezifische Kontaktinformationen und Einstellungen
173 * //[domain_realm]// Definiert die Zuordnung von Server Host-Namen zu Kerberos Realms
174
175 ===== [libdefaults] =====
176
177 Der Abschnitt //[libdefaults]// kann folgende Zuordnungen enthalten:
178
179 * **default_realm**: Definiert den standardmäßig zu verwendenden Kerberos Administrationsbereich.
180 * **default_tkt_enctypes**: Definiert eine Liste von unterstützten Sitzungsschlüssel-Verschlüsselungstypen, die der Client anfordern sollte, wenn ein AS (Authentication Server)-Request durchgeführt wird. Die Reihenfolge der einzelnen Typen entspricht ihrer Präferenz vom höchsten zum niedrigsten. Die Werte innerhalb der Liste können mit Komma oder Leerzeichen getrennt werden.
181 * **default_tgs_enctypes**: Definiert eine Liste von unterstützten Sitzungsschlüssel-Verschlüsselungstypen, die der Client anfordern sollte, wenn ein TGS (Ticket Granting Server)-Request durchgeführt wird. Die Reihenfolge der einzelnen Typen entspricht ihrer Präferenz vom höchsten zum niedrigsten. Die Werte innerhalb der Liste können mit Komma oder Leerzeichen getrennt werden.
182 * **permitted_enctypes**: Definiert alle Verschlüsselungstypen, die für den Einsatz in Sitzungsschlüssel-Verschlüsselung erlaubt sind.
183
184 Eine beispielhafte Konfiguration für den //[libdefaults]//-Abschnitt kann folgendermaßen aussehen:
185
186 {{code language="java" title=""}}
187 [libdefaults]
188 default_realm = EXAMPLE.COM
189 default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4-hmac
190 default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4-hmac
191 permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4-hmac
192 {{/code}}
193
194 ===== [realms] =====
195
196 Jeder Tag im Abschnitt //[realms]// ist der Name eines Kerberos-Administrationsbereichs (auch 'Realm' genannt). Der Wert der Variablen ist eine Auflistung von Zuordnungen, die die Eigenschaften eines bestimmten Realms definieren. Für jeden Realm können die folgenden Zuordnungen definiert werden:
197
198 * **kdc**: Definiert den Namen oder die Adresse eines Rechners auf dem ein KDC (Key Distribution Center) für diesen Administrationsbereich läuft (Meist ist dies der Server, unter dem das Active Directory erreichbar ist). Es kann eine optionale Port-Nummer, getrennt mit Doppelpunkt, angegeben werden.
199
200 Eine beispielhafte Konfiguration für den //[realms]//-Abschnitt kann folgendermaßen aussehen:
201
202 {{code language="java" title=""}}
203 [realms]
204 EXAMPLE.COM = {
205 kdc = domain.example.com
206 }
207 {{/code}}
208
209 ===== [domain_realm] =====
210
211 Der //[domain_realm]// Abschnitt enthält eine Zuordnung von einem Domain-Namen oder den Hostnamen zu einem Kerberos-Realm-Namen. Der Tag-Name kann ein Host oder Domain-Name sein, wobei Domain-Namen mittels Punkt (.) als Vorzeichen gekennzeichnet sind. Als Wert wird der Name eines Kerberos-Realm für diesen bestimmten Host oder die Domäne erwartet. Host- oder Domain-Namen sollten klein geschrieben werden.
212
213 Eine beispielhafte Konfiguration für den //[domain_realm]//-Abschnitt kann folgendermaßen aussehen:
214
215 {{code language="java" title=""}}
216 [domain_realm]
217 .example.com = EXAMPLE.COM
218 {{/code}}
219
220 === Datei login.conf ===
221
222 Hier wird der Inhalt der **login.conf** Datei definiert und damit welche Authentifizierungstechnologie für Client und Server zu verwenden ist.
223
224 Eine beispielhafte Konfiguration kann folgendermaßen aussehen:
225
226 {{code language="java" title=""}}
227 spnego-client {
228 com.sun.security.auth.module.Krb5LoginModule required;
229 };
230
231 spnego-server {
232 com.sun.security.auth.module.Krb5LoginModule required
233 refreshKrb5Config=true
234 storeKey=true
235 isInitiator=false;
236 };
237 {{/code}}
238
239 === Client-Modulname ===
240
241 Der Name, welcher in der //login.conf// Datei für die Definition der Clients verwendet wird.
242
243 === Name des Server-Moduls ===
244
245 Der Name, welcher in der //login.conf// Datei für die Definition des Servers verwendet wird.
246
247 {{error}}
248
249
250 Sollte es bei aktiviertem Kerberos vereinzelt oder dauerhaft zu Fehlern beim Formular-Aufruf kommen (HTTP-Status 400), so überschreitet das Kerberos-Ticket die standardmäßige Größenlimitierung des HTTP-Headers durch den Anwendungsserver (z.B. Tomcat). Eine Lösung bringt die Erhöhung dieser Limitierung welche [[hier>>doc:Main.Beschraenkung der HTTP-Header-Groesse aendern]] beschrieben wird.
251 {{/error}}
252
253 == LDAP Benutzersuche ==
254
255 Die nachfolgenden Einstellungen sind notwendig, um Benutzerinformationen vom authentifizierten Nutzer über LDAP (MS Active Directory) zu beziehen.
256 Die ermittelten Benutzer-Stammdaten stehen anschließend im Formular zur Verfügung.
257
258 === Domain-Controller Host* ===
259
260 FQN (Full Qualified Name) und Port des Active-Directory Controllers.
261 Beispiel: domain.example.com Port: 389
262
263 === SSL-Verbindung ===
264
265 Mit diesem Schalter lässt sich festlegen, ob SSL für den Kommunikation mit dem LDAP-Server verwendet werden soll.
266
267 === Verweis-Sprünge* ===
268
269 Gibt die maximale Anzahl von durchzuführenden Verweis-Sprüngen (Referrels-Hops) auf dem LDAP-Server an.
270 Ein Wert von 0 deaktiviert ein Folgen von Verweisen.
271
272 === Nutzer-Account (mit Domainangabe)* ===
273
274 Dieser Account muss das Recht haben, Suchanfragen (Benutzerobjekt) an das Active-Directory zu senden.
275
276 {{info}}
277 Es wird ein Nutzername mit Domainangabe (FQDN) benötigt.
278 //Beispiel: user@EXCAMPLE.COM //
279 {{/info}}
280
281 === Nutzer-Account Passwort* ===
282
283 Passwort für den oben genannten Nutzer-Account.
284
285 === BaseDn für Suche* ===
286
287 LDAP BaseDN unter der der authentifizierte Benutzer gesucht wird.
288 Beispiel: ou="intern", dc="example", dc="com"
289
290 == Ausgelesene LDAP-Nutzerdaten im Designer verarbeiten ==
291
292 Die zum authentifizierten Nutzer ermittelten Eigenschaften aus dem LDAP werden im **XFC_METADATA**-Objekt abgelegt und stehen dadurch im Formular zur Verfügung. Am JSON-Objekt **currentUser** befindet sich die Eigenschaft **ldap**, welche die ermittelten Daten als JSON-Struktur beinhaltet.
293
294 {{info}}
295 Welche Daten die JSON-Struktur unter der **ldap** Eigenschaft beinhaltet, hängt maßgeblich von den Leserechten des LDAP-Accounts ab,
296 welcher die Nutzersuche im LDAP-System durchführt.
297 {{/info}}
298
299 Das nachfolgende JS-Codeschnipsel zeigt einen Zugriff auf die LDAP-Eigenschaft //userPrincipalName// mittels JS im Designer:
300
301 {{code language="javascript" title=""}}
302 try {
303 // Auslesen der Property und Anzeige in einem Label
304 var elem = $('[name=txt1]');
305 var ldap = XFC_METADATA.currentUser.ldap;
306 if(ldap.hasOwnProperty('userPrincipalName')) {
307 elem.append(ldap.userPrincipalName);
308 }
309 } catch (err) {}
310 {{/code}}

Navigation

Copyright 2000-2025