Änderungen von Dokument Einmalanmeldung


Von Version 6.1
bearbeitet von jdr
am 19.07.2021, 16:08
Änderungskommentar: Löschung des Bildes single_sign_on_ntlm_en.png
Auf Version 18.1
bearbeitet von MKO
am 08.09.2023, 19:37
Änderungskommentar: Es gibt keinen Kommentar für diese Version

Zusammenfassung

Details

Seiteneigenschaften
Dokument-Autor
... ... @@ -1,1 +1,1 @@
1 -XWiki.jdr
1 +XWiki.mko
Inhalt
... ... @@ -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// 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.
single_sign_on_kerberos_de.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.jdr
Größe
... ... @@ -1,0 +1,1 @@
1 +49.5 KB
Inhalt
single_sign_on_kerberos_en.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.jdr
Größe
... ... @@ -1,0 +1,1 @@
1 +46.1 KB
Inhalt
single_sign_on_ntlm_de.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.jdr
Größe
... ... @@ -1,0 +1,1 @@
1 +49.0 KB
Inhalt
single_sign_on_ntlm_en.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.jdr
Größe
... ... @@ -1,0 +1,1 @@
1 +46.9 KB
Inhalt