| ... |
... |
@@ -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. |
|
18 |
+{{smallcaps}}Ntlm{{/smallcaps}} ist nur verfügbar, wenn die Lizenz dies erlaubt. |
| 19 |
19 |
{{/info}} |
| 20 |
20 |
|
| 21 |
21 |
== NTLM nutzen == |
| ... |
... |
@@ -142,7 +142,7 @@ |
| 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"]]. |
|
145 |
+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||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 |
146 |
{{/info}} |
| 147 |
147 |
|
| 148 |
148 |
=== Passwort === |
| ... |
... |
@@ -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. |
