Wiki-Quellcode von Einmalanmeldung


Zeige letzte Bearbeiter
1 Die //Einmalanmeldung// für {{smallcaps}}Ntlm{{/smallcaps}} und Kerberos ist ein kostenpflichtiges {{formcycle/}} Zusatzmodul.
2
3 {{content/}}
4
5 {{warning}}
6 Wir möchten Sie darauf hinweisen, dass wir uns zukünftig von {{smallcaps}}Ntlm{{/smallcaps}} als Option für die Einmalanmeldung verabschieden. Wir folgen dabei einer allgemeinen Empfehlung von Microsoft, wonach {{smallcaps}}Ntlm{{/smallcaps}} aufgrund unzureichender Sicherheitsmechanismen, zukünftig nicht mehr von Anwendungen verwendet werden sollte ([[Stellungnahme von Microsoft>>https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/1e846608-4c5f-41f4-8454-1b91af8a755b?redirectedfrom=MSDN||rel="noopener noreferrer" target="_blank"]] oder [[Stellungnahme im Forum>>https://answers.microsoft.com/en-us/msoffice/forum/all/ntlm-vs-kerberos/d8b139bf-6b5a-4a53-9a00-bb75d4e219eb||rel="noopener noreferrer" target="_blank"]] unter Chapter 3). Daraufhin wurden durch Microsoft Patches zur Verbesserung der Sicherheit veröffentlich, welche mit der aktuellen {{smallcaps}}Ntlm{{/smallcaps}}-Implementierung in FORMCYCLE aber nicht mehr funktionieren wird. Da von einer weiteren Verwendung abgeraten wird, werden wir die Weiterentwicklung des Moduls ab FORMCYCLE Version 7 einstellen.
7
8 Für bestehende Kunden bieten wir Ihnen an, kostenfrei auf Kerberos umzustellen. Die Freischaltung für Kerberos erfolgt in Lizenz der V7 automatisch, wenn {{smallcaps}}Ntlm{{/smallcaps}} bereits lizensiert wurde.
9 {{/warning}}
10
11 {{figure image="single_sign_on_ntlm_de.png" width="600"}}
12 Nutzeroberfläche für die Einstellungen zu {{smallcaps}}Ntlm{{/smallcaps}}. Sie ist nur verfügbar, wenn die Lizenz dies erlaubt.
13 {{/figure}}
14
15 {{smallcaps}}Ntlm{{/smallcaps}} wird für die Authentifizierung von Formularbenutzern verwendet. Ein typisches Einsatzszenario sind Formulare, die intern von Mitarbeitern eines Unternehmens aufgerufen werden. Über {{smallcaps}}Ntlm{{/smallcaps}} kann das Formular auf die Benutzerdaten des angemeldeten ActiveDirectory zugreifen.
16
17 {{info}}
18 {{smallcaps}}Ntlm{{/smallcaps}} bzw. {{smallcaps}}Kerberos{{/smallcaps}} ist nur verfügbar, wenn die Lizenz dies erlaubt.
19 {{/info}}
20
21 == NTLM nutzen ==
22
23 Mit diesem Schalter lässt sich die {{smallcaps}}Ntlm{{/smallcaps}}-Benutzerauthentifizierung für Formulare aktivieren bzw. deaktivieren
24
25 === Mit {{fserver/}} synchronisieren ===
26
27 Wenn dieser Schalter aktiviert ist, wird beim Speichern der Einstellungen die aktuelle Konfiguration auf alle (erreichbaren) {{fserver number="plurar"/}} übertragen.
28
29 === Domain-Controller Host ===
30
31 Host (FQN) des ActiveDirectory Controller für die {{smallcaps}}Ntlm{{/smallcaps}}-Authentifizierung eines Benutzers und die anschließende Ermittlung dessen Daten über {{smallcaps}}Ldap{{/smallcaps}}.
32
33 {{code language="none"}}
34 Beispiel: domain.example.de
35 {{/code}}
36
37 == NTLM-Authentifizierung ==
38
39 Die folgenden Einstellungen sind für die Authentifizierung eines Benutzers mittels {{smallcaps}}Ntlm{{/smallcaps}} notwendig:
40
41 === Hostname des Domain-Controller Hosts ===
42
43 Hostname des Active-Directory-Controller.
44
45 {{code language="none"}}
46 Beispiel: domain
47 {{/code}}
48
49 === Windows-Domainname ===
50
51 Hier können je nach AD verschiedene Schreibweisen des Domainnamen verwendet werden.
52
53 {{code language="none"}}
54 Beispiel: example.de oder example0
55 {{/code}}
56
57 {{info}}
58 Hier muss der Domain-Name angegeben werden, zu denen die zu authentifizierenden Benutzerkonten gehören.
59 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).
60
61 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:
62 **echo %userdomain%**
63 {{/info}}
64
65 === Computerkonto ===
66
67 Dieses Computerkonto muss die Berechtigung zu Nutzerverifizierung haben. Hierbei darf es sich **nicht** um ein Active-Directory Nutzerkonto handeln!
68
69 {{info}}
70 Ein Computer-Account ist am '$'-Zeichen im Domain-Namen erkennbar. z.B. example$@domain.de
71 {{/info}}
72
73 Beschreibung für die Vorgehensweise zur Erzeugung eines Computer-Accounts im //Active Directory Server// können wir aktuell nicht liefern und muss in der entsprechenden Dokumentation von externen Quellen bezogen werden.
74
75 === Computerkontopasswort ===
76
77 Passwort des Computerkontos
78
79 == LDAP-Benutzersuche ==
80
81 Die folgenden Einstellungen sind für eine Nutzersuche nach erfolgter {{smallcaps}}Ntlm{{/smallcaps}}-Authentifizierung notwendig:
82
83 === Port ===
84
85 Der zu verwende Port für die Verbindung mit dem {{smallcaps}}Ldap{{/smallcaps}}-Server zur Nutzersuche
86
87 === SSL-Verbindung ===
88
89 Ermöglich das Aktivierung der SSL-verschlüsselten Kommunikation mit dem {{smallcaps}}Ldap{{/smallcaps}}-Server.
90
91 === Verweis-Sprünge ===
92
93 Gibt die Anzahl der zu folgenden Verweis-Sprünge (Referrals) an. ein Wert von 0 deaktiviert das Folgen von Verweisen.
94
95 === Nutzerkonto (mit Domainangabe) ===
96
97 Konto für die Benutzersuche innerhalb des {{smallcaps}}Ldap{{/smallcaps}}-Servers. Dieses Konto muss entsprechende Rechte für eine Nutzersuche besitzen.
98
99 {{code language="none"}}
100 Beispiel: ldap@example.de
101 {{/code}}
102
103 === Nutzerkontopasswort ===
104
105 Passwort des Nutzerkontos
106
107 === BaseDN für Suche ===
108
109 {{smallcaps}}Ldap{{/smallcaps}} BaseDN unter der die zu authentifizierten Benutzer gesucht werden sollen.
110
111 {{code language="none"}}
112 Beispiel: ou="users", dc="example", dc="de"
113 {{/code}}
114
115 == Einstellungen für Kerberos Authentifizierung ==
116
117 {{figure image="single_sign_on_kerberos_de.png" width="600"}}
118 Nutzeroberfläche für die Einstellungen zu Kerberos. Nur verfügbar, wenn die Lizens dies erlaubt.
119 {{/figure}}
120
121 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.
122
123 Kerberos muss als Lizenz-Option freigeschaltet sein!
124 Ist dies der Fall, können folgende Einstellungen bearbeitet werden:
125
126 === Kerberos nutzen ===
127
128 Mit diesem Schalter lässt sich die Kerberos-Benutzerauthentifizierung für Formulare aktivieren/deaktivieren
129
130 === Mit {{fserver/}} synchronisieren ===
131
132 Wenn dieser Schalter aktiviert ist, wird beim Speichern der Einstellungen die aktuelle Konfiguration auf alle (erreichbaren) {{fserver number="plural"/}} übertragen.
133
134 === Nutzername ===
135
136 Windows Domain Account, welcher für den Zugriff auf das Key Distribution Center (KDC) benötigt wird, um den nachfolgenden Authentifizierungsprozess einzuleiten.
137 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.
138
139 {{info}}
140 Es wird ein Nutzername mit Domainangabe (FQDN) benötigt, wenn in der **krb5.conf** Datei, unter dem Abschnitt //[libdefaults]//, kein **default_realm** definiert ist.
141 //Beispiel: user@EXCAMPLE.COM //
142 {{/info}}
143
144 {{info}}
145 Diesem Benutzer müssen z.B. im Active Directory die zu verwendeten **Hosts der aufrufbaren URLs **als auch der **Computer-Name** (Rechnername und FQDN innerhalb der Domäne) des Anwendungsservers als ServicePrincipalName (SPN) beginnend mit der Serviceklasse HTTP registriert werden. Mehr dazu finden Sie [[hier>>https://social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spn-setspn-syntax.aspx||rel="noopener noreferrer" target="_blank"]] oder [[hier>>https://docs.microsoft.com/en-us/windows-server/networking/sdn/security/kerberos-with-spn||rel="noopener noreferrer" target="_blank"]].
146 {{/info}}
147
148 === Passwort ===
149
150 Passwort des oben genannten Service-Accounts
151
152 === Datei krb5.conf ===
153
154 Hier wird der Inhalt der **krb5.conf** Datei definiert, in welcher die Konfiguration für Kerberos festgelegt werden.
155 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.
156
157 ==== Dateistruktur ====
158
159 Die zu verwendende Schreibweise innerhalb der Datei orientiert sich an Windows INI-Dateien, das heißt, einzelne Abschnitte werden mit
160 einen Abschnittsnamen (in eckigen Klammern) versehen. Jeder Abschnitt enthält keine oder mehrere Zuordnungen,
161 die in folgender Form definiert werden können:
162
163 {{code language="java" title=""}}
164 foo = bar
165 {{/code}}
166
167 oder
168
169 {{code language="java" title=""}}
170 foobar = {
171 foo = bar
172 some = input
173 }
174 {{/code}}
175
176 ==== Abschnittsnamen ====
177
178 * //[libdefaults]//: Enthält die Einstellungen die von der Kerberos V5-Bibliothek verwendet werden
179 * //[realms]//: Realm-spezifische Kontaktinformationen und Einstellungen
180 * //[domain_realm]// Definiert die Zuordnung von Server Host-Namen zu Kerberos Realms
181
182 ===== [libdefaults] =====
183
184 Der Abschnitt //[libdefaults]// kann folgende Zuordnungen enthalten:
185
186 * **default_realm**: Definiert den standardmäßig zu verwendenden Kerberos Administrationsbereich.
187 * **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.
188 * **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.
189 * **permitted_enctypes**: Definiert alle Verschlüsselungstypen, die für den Einsatz in Sitzungsschlüssel-Verschlüsselung erlaubt sind.
190
191 Eine beispielhafte Konfiguration für den //[libdefaults]//-Abschnitt kann folgendermaßen aussehen:
192
193 {{code language="java" title=""}}
194 [libdefaults]
195 default_realm = EXAMPLE.COM
196 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
197 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
198 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
199 {{/code}}
200
201 ===== [realms] =====
202
203 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:
204
205 * **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.
206
207 Eine beispielhafte Konfiguration für den //[realms]//-Abschnitt kann folgendermaßen aussehen:
208
209 {{code language="java" title=""}}
210 [realms]
211 EXAMPLE.COM = {
212 kdc = domain.example.com
213 }
214 {{/code}}
215
216 ===== [domain_realm] =====
217
218 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.
219
220 Eine beispielhafte Konfiguration für den //[domain_realm]//-Abschnitt kann folgendermaßen aussehen:
221
222 {{code language="java" title=""}}
223 [domain_realm]
224 .example.com = EXAMPLE.COM
225 {{/code}}
226
227 === Datei login.conf ===
228
229 Hier wird der Inhalt der **login.conf** Datei definiert und damit welche Authentifizierungstechnologie für Client und Server zu verwenden ist.
230
231 Eine beispielhafte Konfiguration kann folgendermaßen aussehen:
232
233 {{code language="java" title=""}}
234 spnego-client {
235 com.sun.security.auth.module.Krb5LoginModule required;
236 };
237
238 spnego-server {
239 com.sun.security.auth.module.Krb5LoginModule required
240 refreshKrb5Config=true
241 storeKey=true
242 isInitiator=false;
243 };
244 {{/code}}
245
246 === Client-Modulname ===
247
248 Der Name, welcher in der //login.conf// Datei für die Definition der Clients verwendet wird.
249
250 === Name des Server-Moduls ===
251
252 Der Name, welcher in der //login.conf// Datei für die Definition des Servers verwendet wird.
253
254 {{error}}
255 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:Formcycle.SystemSettings.TomcatSettings.LimitHTTPHeader]] beschrieben wird.
256 {{/error}}
257
258 == LDAP Benutzersuche ==
259
260 Die nachfolgenden Einstellungen sind notwendig, um Benutzerinformationen vom authentifizierten Nutzer über LDAP (MS Active Directory) zu beziehen.
261 Die ermittelten Benutzer-Stammdaten stehen anschließend im Formular zur Verfügung.
262
263 === Domain-Controller Host* ===
264
265 FQN (Full Qualified Name) und Port des Active-Directory Controllers.
266 Beispiel: domain.example.com Port: 389
267
268 === SSL-Verbindung ===
269
270 Mit diesem Schalter lässt sich festlegen, ob SSL für den Kommunikation mit dem LDAP-Server verwendet werden soll.
271
272 === Verweis-Sprünge* ===
273
274 Gibt die maximale Anzahl von durchzuführenden Verweis-Sprüngen (Referrels-Hops) auf dem LDAP-Server an.
275 Ein Wert von 0 deaktiviert ein Folgen von Verweisen.
276
277 === Nutzer-Account (mit Domainangabe)* ===
278
279 Dieser Account muss das Recht haben, Suchanfragen (Benutzerobjekt) an das Active-Directory zu senden.
280
281 {{info}}
282 Es wird ein Nutzername mit Domainangabe (FQDN) benötigt.
283 //Beispiel: user@EXCAMPLE.COM //
284 {{/info}}
285
286 === Nutzer-Account Passwort* ===
287
288 Passwort für den oben genannten Nutzer-Account.
289
290 === BaseDn für Suche* ===
291
292 LDAP BaseDN unter der der authentifizierte Benutzer gesucht wird.
293 Beispiel: ou="intern", dc="example", dc="com"
294
295 == Theoretische Betrachtung der Anbindung mehrerer KDCs/Domänen ==
296
297 Sollten mehrere KDC-Server bzw. Domänen für eine übergreifende Anmeldemöglichkeit mittels Kerberos gewünscht sein, ist dies über den Standard der von Java mitgelieferten und von FORMCYCLE verwendeten Kerberos-Implementierung des MIT theoretisch möglich. Zu beachten sind hier jedoch folgende Konfigurationen:
298
299 * Für jeden KDC-Server/jede Domäne ist ein eigener Realm zu definieren
300 * Anhand der unter [domain_realm] zu definierenden Liste ist anzugeben welche Aufruf-URL von welchem Realm behandelt werden soll
301 * Sollte eine Cross Realm Authentifizierung gewünscht sein, so muss ein Cross Realm Trust aufgebaut werden. Dies dient dazu, dass ein Benutze aus Realm A sich auch innerhalb des Realms B anmelden kann. Realisieren lässt sich dies unter anderem mit einem direkten Realm Trust bei dem auf jedem relevanten Server Principals gegen die anderen Realms angelegt werden. Bei den Realms A.REALM.COM und B.REALM.COM wäre dies beispielhaft krbtgt/A.REALM.COM@B.REALM.COM und krbtgt/B.REALM.COM@A.REALM.COM.
302 * Benutzen Sie in für den Service Principal denselben Namen und ein starkes Passwort oder konfigurieren Sie eine keytab-Datei.
303 * Um nach erfolgter Kerberos-Anmeldung die korrekten Benutzer-Daten abzufragen, muss entweder ein LDAP-Server mit Zugriff in den kompletten Forest der Realms oder die Funktionalität der Mandant-Spezifischen LDAP-Server konfiguriert werden. Ggf. ist ferner eine Anpassung des hierfür zuständigen LDAP-Filters notwendig (siehe [[Troubleshooting Kerberos>>doc:.Troubleshooting Kerberos.WebHome||anchor="HKeineBenutzerdatennacherfolgreichemLogin" target="_blank"]])
304
305 == Ausgelesene LDAP-Nutzerdaten im Designer verarbeiten ==
306
307 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 **user** befindet sich die Eigenschaft **rawData**, welche die ermittelten Daten als JSON-Struktur beinhaltet.
308
309 {{info}}
310 Welche Daten die JSON-Struktur unter der **rawData **Eigenschaft beinhaltet, hängt maßgeblich von den Leserechten des LDAP-Accounts ab,
311 welcher die Nutzersuche im LDAP-System durchführt.
312 {{/info}}
313
314 Das nachfolgende JS-Codeschnipsel zeigt einen Zugriff auf die LDAP-Eigenschaft //userPrincipalName// mittels JS im Designer:
315
316 {{code language="javascript"}}
317 try {
318 // Auslesen der Property und Anzeige in einem Label
319 var elem = $('[name=txt1]');
320 var ldap = XFC_METADATA.user.rawData;
321 if(ldap.hasOwnProperty('userPrincipalName')) {
322 elem.html(ldap.userPrincipalName);
323 }
324 } catch (err) {}
325 {{/code}}