... |
... |
@@ -2,6 +2,12 @@ |
2 |
2 |
|
3 |
3 |
{{content/}} |
4 |
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 |
+ |
5 |
5 |
{{figure image="single_sign_on_ntlm_de.png" width="600"}} |
6 |
6 |
Nutzeroberfläche für die Einstellungen zu {{smallcaps}}Ntlm{{/smallcaps}}. Sie ist nur verfügbar, wenn die Lizenz dies erlaubt. |
7 |
7 |
{{/figure}} |
... |
... |
@@ -9,7 +9,7 @@ |
9 |
9 |
{{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. |
10 |
10 |
|
11 |
11 |
{{info}} |
12 |
|
-{{smallcaps}}Ntlm{{/smallcaps}} ist nur verfügbar, wenn die Lizenz dies erlaubt. |
|
18 |
+{{smallcaps}}Ntlm{{/smallcaps}} bzw. {{smallcaps}}Kerberos{{/smallcaps}} ist nur verfügbar, wenn die Lizenz dies erlaubt. |
13 |
13 |
{{/info}} |
14 |
14 |
|
15 |
15 |
== NTLM nutzen == |
... |
... |
@@ -64,7 +64,7 @@ |
64 |
64 |
Ein Computer-Account ist am '$'-Zeichen im Domain-Namen erkennbar. z.B. example$@domain.de |
65 |
65 |
{{/info}} |
66 |
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>>https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-api-management/api-gateway/9-3/policy-assertions/assertion-palette/access-control-assertions/require-ntlm-authentication-credentials-assertion/creating-a-computer-account-for-ntlm-authentication.html||rel="__blank" title="Creating a Computer Account for NTLM Authentication"]] |
|
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. |
68 |
68 |
|
69 |
69 |
=== Computerkontopasswort === |
70 |
70 |
|
... |
... |
@@ -136,10 +136,9 @@ |
136 |
136 |
{{/info}} |
137 |
137 |
|
138 |
138 |
{{info}} |
139 |
|
-Diesem Benutzer müssen z.B. im Active Directory die zu verwendeten Domians als ServiePrincipalName 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||target="_blank"]] oder [[hier>>https://docs.microsoft.com/en-us/windows-server/networking/sdn/security/kerberos-with-spn||target="_blank"]]. |
|
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"]]. |
140 |
140 |
{{/info}} |
141 |
141 |
|
142 |
|
-(% class="wikigeneratedid" %) |
143 |
143 |
=== Passwort === |
144 |
144 |
|
145 |
145 |
Passwort des oben genannten Service-Accounts |
... |
... |
@@ -287,6 +287,16 @@ |
287 |
287 |
LDAP BaseDN unter der der authentifizierte Benutzer gesucht wird. |
288 |
288 |
Beispiel: ou="intern", dc="example", dc="com" |
289 |
289 |
|
|
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 |
+ |
290 |
290 |
== Ausgelesene LDAP-Nutzerdaten im Designer verarbeiten == |
291 |
291 |
|
292 |
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 **user** befindet sich die Eigenschaft **rawData**, welche die ermittelten Daten als JSON-Struktur beinhaltet. |