| ... |
... |
@@ -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. |
