Changes for page Einmalanmeldung

From version 5.1
edited by MKO
on 20.05.2022, 10:20
Change comment: There is no comment for this version
To version 7.1
edited by MKO
on 08.09.2023, 19:40
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -148,7 +148,7 @@
148 148  {{/info}}
149 149  
150 150  {{info}}
151 -To this user you must, in Active Directory for example, register the **domians **and the **computer name** to be used as ServiePrincipalName beginning with the service class HTTP. You can find more information [[here>>https://social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spn-setspn-syntax.aspx||rel="noopener noreferrer" target="_blank"]] or [[here>>https://docs.microsoft.com/en-us/windows-server/networking/sdn/security/kerberos-with-spn||rel="noopener noreferrer" target="_blank"]].
151 +To this user you must, in Active Directory for example, register the **hosts of the urls** and the **computer name** (computer name and FQDN inside the domain) to be used as ServicePrincipalName (SPN) beginning with the service class HTTP. You can find more information [[here>>https://social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spn-setspn-syntax.aspx||rel="noopener noreferrer" target="_blank"]] or [[here>>https://docs.microsoft.com/en-us/windows-server/networking/sdn/security/kerberos-with-spn||rel="noopener noreferrer" target="_blank"]].
152 152  {{/info}}
153 153  
154 154  === Password ===
... ... @@ -290,6 +290,16 @@
290 290  
291 291  Example: {{code language="none"}}ou="intern", dc="example", dc="com"{{/code}}
292 292  
293 +== Theoretical consideration of the connection of several KDCs/domains ==
294 +
295 +If multiple KDC servers or domains are desired for a global Kerberos login ability, this is theoretically possible via the standard MIT Kerberos implementation provided by Java and used by FORMCYCLE. However, the following configurations should be noted here:
296 +
297 +* For each KDC server/domain a separate realm must be defined.
298 +* The list to be defined under [domain_realm] must be used to specify which request URL should be handled by which realm.
299 +* If cross realm authentication is desired, a cross realm trust must be established. This serves to the purpose that a user from realm A can also log in within the realm B. For example, this can be realized with a direct realm trust where principals are created on each relevant server against the other realms. For the realms A.REALM.COM and B.REALM.COM this would be for exemplary krbtgt/A.REALM.COM@B.REALM.COM and krbtgt/B.REALM.COM@A.REALM.COM.
300 +* Use the same name and a strong password for the service principal or configure a keytab file.
301 +* To query the correct user data after the Kerberos login, either an LDAP server with access to the whole forest of the realms or the functionality of the client-specific LDAP servers must be configured. It may also be necessary to adjust the responsible LDAP filter.
302 +
293 293  == Make user data available to forms ==
294 294  
295 295  The LDAP user data for the currently authenticated user are stored in the JavaScript object {{code language="none"}}window.XFC_METADATA.user.rawData{{/code}} and can be accessed via JavaScript.