| ... |
... |
@@ -290,16 +290,6 @@ |
| 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 |
|
- |
| 303 |
303 |
== Make user data available to forms == |
| 304 |
304 |
|
| 305 |
305 |
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. |
