Änderungen von Dokument Einmalanmeldung


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

Zusammenfassung

Details

Seiteneigenschaften
Dokument-Autor
... ... @@ -1,1 +1,1 @@
1 -XWiki.mko
1 +XWiki.jdr
Inhalt
... ... @@ -2,12 +2,6 @@
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 -
11 11  {{figure image="single_sign_on_ntlm_de.png" width="600"}}
12 12  Nutzeroberfläche für die Einstellungen zu {{smallcaps}}Ntlm{{/smallcaps}}. Sie ist nur verfügbar, wenn die Lizenz dies erlaubt.
13 13  {{/figure}}
... ... @@ -15,7 +15,7 @@
15 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 16  
17 17  {{info}}
18 -{{smallcaps}}Ntlm{{/smallcaps}} bzw. {{smallcaps}}Kerberos{{/smallcaps}} ist nur verfügbar, wenn die Lizenz dies erlaubt.
12 +{{smallcaps}}Ntlm{{/smallcaps}} ist nur verfügbar, wenn die Lizenz dies erlaubt.
19 19  {{/info}}
20 20  
21 21  == NTLM nutzen ==
... ... @@ -70,7 +70,7 @@
70 70  Ein Computer-Account ist am '$'-Zeichen im Domain-Namen erkennbar. z.B. example$@domain.de
71 71  {{/info}}
72 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.
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"]]
74 74  
75 75  === Computerkontopasswort ===
76 76  
... ... @@ -142,9 +142,10 @@
142 142  {{/info}}
143 143  
144 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"]].
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"]].
146 146  {{/info}}
147 147  
142 +(% class="wikigeneratedid" %)
148 148  === Passwort ===
149 149  
150 150  Passwort des oben genannten Service-Accounts
... ... @@ -292,16 +292,6 @@
292 292  LDAP BaseDN unter der der authentifizierte Benutzer gesucht wird.
293 293  Beispiel: ou="intern", dc="example", dc="com"
294 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 305  == Ausgelesene LDAP-Nutzerdaten im Designer verarbeiten ==
306 306  
307 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.
single_sign_on_kerberos_de.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.jdr
Größe
... ... @@ -1,1 +1,0 @@
1 -49.5 KB
Inhalt
single_sign_on_kerberos_en.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.jdr
Größe
... ... @@ -1,1 +1,0 @@
1 -46.1 KB
Inhalt
single_sign_on_ntlm_de.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.jdr
Größe
... ... @@ -1,1 +1,0 @@
1 -49.0 KB
Inhalt
single_sign_on_ntlm_en.png
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.jdr
1 +XWiki.nlo
Größe
... ... @@ -1,1 +1,1 @@
1 -46.9 KB
1 +35.8 KB
Inhalt