A number of alternative authentication subsystem types exist for the most commonly used authentication protocols. These are each identified by a unique type name.
The following table shows the authentication subsystem types supplied and the optional features they support.
| Type | Description | Single Sign-On (SSO) support | User registry entry |
|---|---|---|---|
| alfrescoNtlm | Native Content Services authentication | No | No |
| ldap | Authentication and user registry export through the LDAP protocol (for example, OpenLDAP) | No | Yes |
| ldap-ad | Authentication and user registry export from Active Directory through the LDAP protocol | No | Yes |
| kerberos | Authentication through a Kerberos realm | Yes, SPNEGO | No |
| external | Authentication using an external SSO mechanism | Yes | No |
| identity-service | Authentication using the Identity Service | Yes | No |
CAUTION: Single Sign On (SSO) can be used for Content Services and Alfresco Office Services. Still, SSO is not fully
implemented when mapping a PC network drive over WebDAV, that is to either
<alfresco_host>/alfresco/webdav or
<alfresco_host>/alfresco/aos endpoint. As a workaround, PC
users must first log on to Content Services using SSO before mapping
the drive; otherwise, the mapping request may fail. Users using the Identity Service as
their authentication subsystem can also use basic authentication to log on over WebDAV,
provided the identity-service.enable-basic-auth property is set to
true.
Note: Support for Microsoft Office depends on the authentication
mechanism provided by the external subsystem. See External authentication and SSO for more information.
If you’re using a proxy (load balancer) with Kerberos authentication, either:
- Use the external authentication subsystem and set up the proxy to implement kerberos
- Set up the kerberos authentication subsystem and create the Service Principal Name (SPN) in Active Directory to include the proxy DNS name