... |
... |
@@ -2,6 +2,12 @@ |
2 |
2 |
|
3 |
3 |
{{content/}} |
4 |
4 |
|
|
5 |
+{{warning}} |
|
6 |
+We would like to inform you that in future we will say goodbye to {{smallcaps}}Ntlm{{/smallcaps}} as an option for single sign-on. We are following a general recommendation from Microsoft, according to which {{smallcaps}}Ntlm{{/smallcaps}} should no longer be used by applications in the future due to insufficient security mechanisms ([[statement from Microsoft>>https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/1e846608-4c5f-41f4-8454-1b91af8a755b?redirectedfrom=MSDN||rel="noopener noreferrer" target="_blank"]] or [[statement in the forum>>https://answers.microsoft.com/en-us/msoffice/forum/all/ntlm-vs-kerberos/d8b139bf-6b5a-4a53-9a00-bb75d4e219eb||rel="noopener noreferrer" target="_blank"]] under Chapter 3). Microsoft then published patches to improve security, but these will no longer work with the current {{smallcaps}}Ntlm{{/smallcaps}} implementation in FORMCYCLE. Since it is not recommended to continue using the module, we will stop further development of the module from FORMCYCLE version 7 onwards. |
|
7 |
+ |
|
8 |
+For existing customers we offer to switch to Kerberos for free. The activation for Kerberos is done automatically in the licence of V7, if {{smallcaps}}Ntlm{{/smallcaps}} has already been licensed. |
|
9 |
+{{/warning}} |
|
10 |
+ |
5 |
5 |
{{figure image="single_sign_on_ntlm_en.png" width="600"}} |
6 |
6 |
User interface for setting up {{smallcaps}}Ldap{{/smallcaps}} authentication via {{smallcaps}}Ntlm{{/smallcaps}}. Available only if the license allows it. |
7 |
7 |
{{/figure}} |
... |
... |
@@ -142,7 +142,7 @@ |
142 |
142 |
{{/info}} |
143 |
143 |
|
144 |
144 |
{{info}} |
145 |
|
-To this user you must, in Active Directory for example, register the Domians 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"]]. |
146 |
146 |
{{/info}} |
147 |
147 |
|
148 |
148 |
=== Password === |
... |
... |
@@ -284,6 +284,16 @@ |
284 |
284 |
|
285 |
285 |
Example: {{code language="none"}}ou="intern", dc="example", dc="com"{{/code}} |
286 |
286 |
|
|
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 |
+ |
287 |
287 |
== Make user data available to forms == |
288 |
288 |
|
289 |
289 |
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. |