3. Document information
Authentication 3
Document information
Information in this document is subject to change without notice. No part of this document
may be reproduced or transmitted in any form or by any means, electronic or mechanical,
for any purpose, without the express written permission of Alfresco. The trademarks,
service marks, logos, or other intellectual property rights or Alfresco and others used in this
documentation("Trademarks") are the property of Alfresco and their respective owners. The
furnishing of this document does not give you license to these patents, trademarks, copyrights or
other intellectual property except as expressly provided in any written agreement with Alfresco.
The United States export control laws and regulations, including the Export Administration
Regulations of the U.S. Department of Commerce, and other applicable laws and regulations
apply to this documentation which prohibit the export or re-export of content, products, services,
and technology to certain countries and persons. You agree to comply with all export laws,
regulations and restrictions of the United States and any foreign agency or authority and assume
sole responsibility for any such unauthorized exportation.
You may not use this documentation if you are a competitor of Alfresco, except with Alfresco's
prior written consent. In addition, you may not use the documentation for purposes of evaluating
its functionality or for any competitive purposes.
If you need technical support for this product, contact Customer Support by email at
support@alfresco.com. If you have comments or suggestions about this documentation, contact
us at training@alfresco.com.
4. Authentication
4 Alfresco Elements
Authentication
Introduction
Before a user can enter the Alfresco system they must be authenticated and in order to ensure
Alfresco retains its flexibility the authentication subsystem is very advanced, but does need you
to understand it fully to get the best out of it. We will see how to configure a remote authentication
system.
Understanding authentication
Before we dive into the configuration of Alfresco authentication it is worthwhile reviewing
authentication in the round and the enterprise issues which are faced with authentication. This is
a review of general knowledge and you may skip this if you are well versed with authentication
and move on to the specifics of authentication with Alfresco. When you install an Alfresco system
it will have one user defined, the admin user. For other people to be able to use the system they
must have user records, or authorities, created in the Alfresco repository. Alfresco uses these
records to be able to track who owns what, which users are in which groups, which users belong
to which sites, how much quota a user has used, and so forth.
As an administrator you can easily create these users directly in the Alfresco repository. If
we want Matt Black as a user in our system we simple use the Share administration interface
and create his record and provide him with a password. From this point Matt can login to our
Alfresco system. For the test scenarios and the smallest applications this is adequate. However
if every application in an organization requires a separate user record then administrators
are soon swamped and it becomes very difficult to manage the creation, update and deletion
of users across an enterprise. This is one of the reasons that many organizations have now
implemented a corporate user directory. This centralized directory holds user credentials and
profile information, and sometimes a group organizational structure. There are a number of
varieties of central directories the most common being Active Directory and LDAP. So if an
organization has implemented a central user directory it makes senses that they should use
it with Alfresco. In this section we see how this can be accomplished using the authentication
subsystem. Even with a single user directory across the organization synchronizing user
credentials Matt would still need to login and provide his credentials to each and every application
he used, not only Alfresco, but other line of business applications, such as email, customer
relationship management system and accounts.
5. Authentication
Authentication 5
In order to provide a user experience that only requires a single login, a single sign-on system
must be put in place. A single sign-on system, simply called SSO, typically integrates with
the user’s login to their desktop or laptop machine and uses these credentials as the means
for authentication to other systems. In some organizations the SSO system and the user
directory system are one and the same. If an organization has implemented a SSO solution
it makes senses that they should use it with Alfresco. In this section we see how this too can
be accomplished. Although there can be, and often is, a relationship between the corporate
user directory and SSO, there does not need to be one. For example it is quite permissible to
implement synchronization with your Active Directory without implementing SSO, similarly it is
possible to implement SSO with just the internal user directory.
Internal
The simplest authentication setup and the one which is enabled by default out of the box, is
to authenticate internally with the Alfresco user directory. In this case we can see that as Matt
provides the URL for Share the server responds with a login dialog. When Matt enters his
username and password these are transmitted to the server which authenticates his credentials
against the internal Alfresco user directory.
6. Authentication
6 Alfresco Elements
Internal with Single sign-on
The internal Alfresco authentication can be configured so that the username and password
which the user has already used to login to their Windows machine is used as the credentials to
authenticate against Alfresco. This is done by enabling NTLM and setting up one or more filters
which negotiate the protocol with the client application. In this case the filter being used is for a
browser, other filters exist for WebDAV and other client access points.
In this setup, and all SSO configurations, the operating system credentials must match those in
the authentication directory, in this case the Alfresco user repository. By using the configuration
when Matt accesses the Share URL he is immediately logged in providing a more seamless user
experience.
7. Authentication
Authentication 7
External
In the setup shown here we see that remote authentication is being used against a corporate
user directory. In this case the process is exactly the same as far as the user, Matt is concerned,
the difference arises at the server, instead of authenticating against the internal Alfresco user
directory, the Alfresco subsystem remotely authenticates against the corporate directory.
8. Authentication
8 Alfresco Elements
It should be noted that even when using a remote user directory for Authentication, a user entry is
required in the internal Alfresco repository, we see shortly how this is dealt with.
Chained
It is very likely that at least one of the authentication subsystem types provided will allow you to
integrate Alfresco with one of the authentication servers in use in your organization. However,
integrating Alfresco with just one of these systems may not be enough. For various reasons, you
might want to mix-and-match multiple authentication protocols against a collection of servers.
That is why Alfresco has a built-in authentication chain. In the simplest terms, this is a priority-
ordered list of authentication attempts. Each authentication is handled by a subsystem instance
which can be independently configured.
In our example we see an authentication chain made up of two subsystems and configured so
that when an authentication request comes in it is first handled by the external subsystem. If
the external subsystem cannot provide a valid authentication then the request flips over to the
internal subsystem, which can then validate the request. It important to note that as soon as one
of the subsystems in the chain has successfully validated, all the other subsystems in the chain
are ignored.
9. Authentication
Authentication 9
There is one exception to this relating to single sign-on and CIFS. These can only be targeted
at a single subsystem instance in the authentication chain. This is a restriction imposed by the
authentication protocols themselves. For this reason, Alfresco targets these ‘direct’ authentication
functions at the first member of the authentication chain that has them enabled, so you should
ensure that only one of the subsystems in the chain is setup to handle SSO.
No synchronization
When using remote authentication the first time a user attempts to login to the system their
user entry will be created in Alfresco, assuming that they have provided the right credentials.
The details are copied from the corporate repository based on the way you have defined the
configuration. The entry copied to the Alfresco repository will be read only and you will not be
able to make change to it there, you will still need to manage your users at the corporate level.
For large user populations this may be an expensive process, furthermore until those user entries
exist in Alfresco they cannot be used in groups, permissions settings, workflow, notifications or
other user centric operations.
Synchronization
For this reason it is possible to get the authentication subsystem provide a regular
synchronization with the LDAP directory, this can be configured to happen when you want but is
typically done on a nightly basis. The synchronization is incremental, so you will find if you have
thousands of users and hundreds of groups the first time synchronization may take a significant
amount of time, but after that it should complete quickly.
The default configuration assumes that people are stored in LDAP as inetOrgPerson objects but
can be changed to match the user type in Active Directory, this is done by configuring the two
queries which the synchronization system submits, one for groups and one for users.
10. Authentication
10 Alfresco Elements
Overview
We have seen how authentication is concerned with validating that a user is who they claim
to be. A user’s credentials can take many forms and can be validated in a number ways.
However the default installation of Alfresco includes the internal, password based, authentication
implementation. Through the authentication subsystem it also provides support to integrate
with many remote authentication environments; for example; a password validation against an
LDAP directory, or Kerberos ticket validation against a Microsoft Active Directory Server. Alfresco
also give the administrator the ability to use several of these options simultaneously through
authentication chaining.
Alfresco can integrate with LDAP, Microsoft Active Directory Server, the Java Authentication
and Authorization Service (JASS), Kerberos, and NTLM. A user ID can also be presented as an
HTML attribute over HTTPS to integrate with web-based single sign-on solutions.
You can see the popularity of different authentication mechanisms in the chart. In this section
we will show you how to setup Alfresco authentication to work with Active Directory using single
sign-on, even if this is not the user directory your organization uses you should still follow the
example through as it illustrates generally applicable techniques which are key concepts and will
be required when you come to attempt the lab.
You even have the option to write your own authentication integration, although this would require
a developer knowledgeable in this area.
Subsystem components
An authentication subsystem is a coordinated stack of compatible components that handle all
authentication-related functions to Alfresco. Each Alfresco authentication subsystem includes
the following components: an authentication component that handles the specifics of talking to
11. Authentication
Authentication 11
the backend authentication system; a user registry export service that exposes information about
users and groups to the synchronization subsystem; authentication filters that provide form or
single sign-on login functions for web clients, WebDAV, web scripts, and Sharepoint protocol; file
server authenticators that provide authentication functions for CIFS and FTP protocols.
It should be noted however that not all subsystems do, or can, provide all of these capabilities.
Authentication subsytem
The Alfresco authentication and identity management functionality is provided by a set of
configurable subsystems. An authentication subsystem provides the following functions to
Alfresco: password based authentication, file system authentication, single sign-on and user
registry export.
Password based authentication is used for a range of protocols, these include HTTP, Microsoft
SharePoint protocol, FTP, and WebDAV. CIFS and NFS file systems support is provided for file
system authentication. Single sign-on is provided for web browser, Microsoft SharePoint protocol,
WebDAV and CIFS in certain situations. The final function, user registry export, is the automatic
population of the Alfresco user and authority database.
Alfresco has the ability to allow guest access without authentication, this can be used by a client
application. For example the old style Alfresco Explorer web client honours this and provides
guest access rather than a login page on first use, this can be disabled and we will see how you
could do this in the labs exercise.
Subsystem composition
Each subsystem instance has; a type, a unique name that makes it distinguishable from other
instances of the same type and a set of property values provided by user configuration.
12. Authentication
12 Alfresco Elements
Each subsystem has its own configuration values in its own configuration files. You can
configure subsystems by making the necessary configuration changes in the alfresco-
global.properties file rather than directly in the subsystem configuration files. We will see
shortly how to do this. These configuration values can also be changed using the JMX console
without stopping the server.
Internal single sign on
The first example we take will be to extend the default authentication to also allow for the simplest
single sign-on scenario. In this case the user directory being used is the one inside the Alfresco
repository. This is the default so the only real difference is the addition of SSO.
In this setup we will configure Alfresco so that when a user accesses Alfresco Share through a
browser Alfresco will conduct a credentials check with the information the user entered when
successfully logging into his client operating system. The user may have originally authenticated
against a domain or simply against the local operating system. In either case their username and
password provided to their client operating system must match those held in Alfresco. Let’s see
how this setup is configured.
Demo: Single sign-on with alfrescoNtlm
The default login uses internal alfrescoNtlm authentication. Let’s explore the changes required to
enable single sign-on.
In this example the Alfresco server is running Linux, the changes necessary are irrespective of
which platform your server is deployed to.
Navigating to <TOMCAT_HOME>/shared/classes I edit the alfresco-global.properties file.
I paste new authentication settings. The first section defines an authentication chain, comprised
of one alfrescoNtlm subsystem, called alfrescoPrimary. This is the default subsystem, so it is
not strictly necessary, but enumerating it in the global properties file highlights the intention. The
second setting enables single sign-on, which enables single sign-on through the authentication
chain. I save the file.
I must enable Share to accept single sign-on. To achieve this I edit the share-config-
custom.xml file, found in the <TOMCAT_HOME>/shared/classes/alfresco/web-extension
This controls the Share user interface behaviour. Scrolling through the file I reach the section that
controls NTLM authentication. I uncomment this section and change localhost to alfresco, the
name of my server. I save the file.
When we edit Alfresco properties using a JMX console we do not need to restart the Alfresco
server for the changes to come into effect, however any time you make a change to an XML
configuration file you will need to restart the server.
Windows client
On a Windows client, where a user logs into their operating system against a domain, we would
now expect a user to be logged in automatically to Alfresco when the Share URL is invoked. The
login prompt is however presented, something has changed, but it isn’t quite right.
This occurs because there is no trusted relationship between the client machine and the Alfresco
server. To fix this, in the Firefox browser I type about:config, then for network.automatic-
ntlm-auth.trusted-uris I enter the alfresco server.
When the URL for Share is next entered, the user is automatically logged in. Single sign-on is
working. You will also notice the logout option is no longer available as this is not relevant.
To achieve this in Internet Explorer go to Internet Options > Security > Trusted Sites >
Sites and add the Alfresco server as a trusted site.
Single sign-on with alfrescoNtlm authentication relies on the username and password for
Windows being the same as for the Alfresco server. In addition, be aware that Windows 7
13. Authentication
Authentication 13
implements NTLM version 2 by default, and must be configured to NTLM version 1 before it
would be possible for single sign-on authentication with Alfresco to work.
In environments where no domain login exists the browser will always make an authentication
request in the browser when first logging in.
Active directory synchronization with single sign on
Now let’s see how to setup an environment which: synchronizes users from an Active Directory
server with Alfresco; authenticates users against the Active Directory server and provides single-
sign on where the user’s operating system credentials are verified against the Active Directory
server.
The synchronization will be setup to happen on server startup and once daily during the night
– this is the default behavior. When users login to their operating system on their laptop or
desktop they are authenticated with the corporate Active Directory server – this is external to
Alfresco and would be part of your corporate infrastructure. However the fact that they have been
authenticated means that when they try to access Alfresco they are automatically signed in as the
Alfresco server will check their credentials against the Active Directory server.
In order to keep our configuration as simple as possible we are going to setup sign-sign on just
for web browser access. We are going to setup chained authentication which uses a remote
Active Directory for our users and replaces the built in Alfresco authentication. Before we look at
the specifics of configuring the Alfresco authentication subsystems with this behavior let’s first
see a pictorial representation of what we will be doing.
As installed out of the box Alfresco is using the built in user directory, alfrescoNtlm. There
are a number of other subsystems provided for authentication, but by default these are not
enabled. Our first step is to enable the right subsystem, in our case we will enable the ldap-ad
subsystem which provides authentication against Active Directory. For our purpose we will stop
using the alfrescoNtlm subsystem. We can now configure the ldap-ad system to provide user
synchronization and authentication.
First we need to create an instance of the ldap-ad authentication subsystem and give it name,
in this case we will to call it enterpriseAD. Our corporate Active Directory server is called ad-
server and our Alfresco server is called alfresco, both of these machines are in the domain
green-energy-demo.com. Next we will want to configure the enterpriseAD subsystem with the
necessary properties to be able to synchronize users from the Active Directory server.
Demo: Active directory with single sign on part 1
Prior to setting up this configuration, let’s login to our Active Directory server and examine how
our Active Directory is configured. We can look at the users and groups by selecting Active
Directory Users and Computers. You can see how we have a very simple setup for our green-
energy-demo.com domain. We have created an organizational unit containing all our users and
groups.
If we look at the properties for a user we can see that items such as first name and surname have
been set as well as the login name and other properties such as the email address. These values
can all be copied to Alfresco during the synchronization process.
As you can see our Alfresco server is running on a Linux machine, but the changes you have to
make on a Windows machine are exactly the same.
The first thing we need to do is to edit the alfresco-global.properties file were we can see
that the settings are configured for using the alfrescoNtlm authentication subsystem and we
have single sign-on enabled. Let’s remove the single sign-on now and replace the alfrescoNtlm
subsystem with an ldap-ad subsystem. Having done this we need to add the configuration
settings for our subsystem which we have called “enterpriseAD”.
The first thing you’ll see is that we have enabled ldap authentication. The next thing we need to
do is to tell the subsystem where the Active Directory server, or naming provider, is. You can see
14. Authentication
14 Alfresco Elements
this accomplished by setting up a URL with a protocol of LDAP and using port 389. This is the
default port for LDAP connections, but may be different in your organization. Our LDAP server
is called ad-server and is found on the green-energy-demo.com domain, yours will certainly be
different.
Next we need to define what should be sent through as the username for the purposes of
authentication, the %s is replaced with whatever the user types in as their userid on the login
screen. The domain name is then appended, for example harriet@green-energy-demo.com.
The next configuration line here determines the authentication type which should be set to
“simple” for Active Directory, for other LDAP servers it may be set to “DIGEST-MD5” or other
available protocols. Note that this authentication mechanism sends user names and passwords in
plain text, this is the most simple to setup and fine for testing. Later we will see how we can use a
different more secure sub-system for authentication.
Finally we can specify a list of users from Active Directory which should be treated as
administrators in the Alfresco system. Having done this we have a basic configuration for
authentication against Active Directory, but we also want to provide a synchronization by
exporting users and groups from Active Diretory into Alfresco. Let’s configure that next. Our next
configuration section makes LDAP synchronization active.
The next two lines are optional, they are only used to access LDAP for the extraction of user
and group information. If they are omitted, then an anonymous authentication will be attempted
however this may not be supported for all authentication mechanisms.
The next two parameters, userSearchBase and groupSearchBase are the LDAP queries which
identify the part of the Active Directory structure to query for users and groups respectively.
These will vary significantly based on the way your Active Directory has been setup and
structured.
The last four parameters we have added specify how the user properties in the LDAP server are
mapped to Alfresco user properties, for example you can see that the Alfresco last name attribute
is taken from the LDAP sn property and the email address is taken from the LDAP property mail
Now we need to save our alfresco-global.properties file.
What we have done is configure synchronization and authentication to our Active Directory
server. The first synchronization will happen as soon as we start the Alfresco server.
Once the server has started we can see that the synchronization has taken effect by looking in
the log file, it shows that the enterpriseAD subsystem has started, it also shows other logging
information about the queries being sent through to LDAP and finally posts the number of groups
and users processed from the target system.
Now our server has started let’s login as the Alfresco administrator and see what we have in our
Alfresco user directory.Remember that we setup the user alfresco to be an administrator,
let’s login as that user.
Navigating to the Admin console we can see that the Marketing group has been copied across
from Active Directory, opening up this group we can see the group’s users have also been
successfully copied.
If we now look at users we can see that the user records have been synchronized, with the
relevant properties copied.
Logging in as Harriet you can see that since her account is synchronized with Active Directory
it is not possible to change her personal information. This should be undertaken in the external
authentication system..
Demo: Active directory with single sign on part 2
15. Authentication
Authentication 15
Now that we have the first part of our configuration working we can move onto the second part
which is to configure single sign-on.
Earlier you saw that the authentication capabilities offered by the ldap-ad subsystem type
were not capable of supporting CIFS and NTLM authentication. Instead, you had to settle
for form-based login for all users, and only Alfresco internal users could access CIFS. This
is the compromise you would have to make if the directory server did not support any other
authentication protocol. But for Active Directory, which also supports NTLM and Kerberos
authentication, you can overcome this limitation by using either the passthru or the kerberos
subsystem types.
Functions such as NTLM single sign-on and CIFS authentication can only be targeted at a single
subsystem instance in the authentication chain. This is a restriction imposed by the authentication
protocols themselves. For this reason, Alfresco targets these direct authentication functions at the
first member of the authentication chain that has them enabled.
In our example we see an authentication chain made up of two subsystems and configured so
that when an authentication request comes in it is first handled by the ldap-ad subsystem. If
the ldap-ad subsystem cannot provide a valid authentication then the request flips over to the
passthru subsystem, which can then provide a response to the caller.
The next task is to declare the customized authentication chain to Alfresco and configure the
passthru subsystem which we will call ssoPassthru. We must once again edit the alfresco-
global.properties configuration file and create an authentication chain with the uniquely
named subsystems. Then we set the configuration properties appropriate to passthru subsystem.
Now that we have synchronization and authentication with our Active Directory server working we
are going to setup single sign-on using our Active Directory server. In order to do this we need to
16. Authentication
16 Alfresco Elements
setup another subsystem which supports single sign-on since we know that the ldap-ad system
does not.
The choices available are kerberos or passthru. Passthru is simpler for demonstration
purposes and this is what we will be using. Our first step is to add a passthru subsystem to our
authentication chain and give it a unique name, in this instance we have called it ssoPassthru.
By now you will have understood that everytime we add a new subsystem we need to configure
it by adding its appropriate parameters. We do this by adding another section to the alfresco-
global.properties file.
Firstly we enable single sign-on, next we need to specify the authentication servers, this needs
to be a comma delimited list of server names or addresses that are used for authentication. The
passthru authenticator will load balance amongst the available servers, and can monitor server
status to determine which are online or offline. Each server name may be prefixed with a domain
name as shown in this example. If the client specifies a domain name in its logon request then
the appropriate server will be used for the authentication. There should be at least one entry in
the server list that does not have a domain prefix, this is the catch all entry that will be used if the
client domain cannot be determined from the NTLM request or via domain mapping.
We have also disabled guest access for older Alfresco web clients which support this and defined
the default administrators for this subsystem. Let’s save the alfresco-global.properties file
and restart the server.
Having completed our setup let’s see what happens when we login to a windows client which
is part of our Green-Energy domain. We will login as Matt Black, you can see that we will be
authenticating against GREEN-ENERGY-DE, which is equivalent to green-energy-demo.com
We have a shortcut on our desktop which will open the browser and takes us to Alfresco. Now
you can see the magic happening, we are automatically logged in as the correct user and so our
setup is complete.
This works well with Windows XP clients. However when using Windows 7 clients you should
note that this by default uses NTLM v2 which is not supported by the passthru subsystem. In
order for this setup to work you will need to alter the security policy on Windows 7 to allow NTLM
v1.
17. Lab - LDAP configuration
Authentication 17
Lab - LDAP configuration
1. This lab addresses the goal of delegating authentication responsibility to a centralized
directory server. Since most organizations maintain their user database in a directory
server supporting the LDAP protocol, such as Active Directory or OpenLDAP, this is one of
the things you should be familiar with as an Alfresco administrator
When integrated with an LDAP server, Alfresco can delegate both the password checking
and account setup to the LDAP server, thus opening up Alfresco to your entire enterprise.
To integrate Alfresco with a directory server, you simply need to include an instance of
the ldap or ldap-ad subsystem types in the authentication chain. Both subsystem types
offer exactly the same capabilities and should work with virtually any directory server
supporting the LDAP protocol. Their only differences are the default values configured
for their attributes. The ldap-ad type is preconfigured with defaults appropriate for Active
Directory, whereas ldap is preconfigured with defaults appropriate for OpenLDAP. This
lab uses an OpenLDAP server and therefore will configure in an instance of the ldap
subsystem.
You have two choices in this scenario; you can either replace the existing authentication
chain or add to it.
You could remove the default alfrescoNtlm from alfresco-global.properties file and
instead add an instance of ldap. This would hand over all authentication responsibility to
OpenLDAP and would mean that the built in accounts, such as admin and guest, could not
be used.
18. Lab - LDAP configuration
18 Alfresco Elements
In this scenario, it would be important to configure at least one user who exists in
OpenLDAP as an administrator and enable the guest account in OpenLDAP if guest
access were required. Furthermore, because ldap cannot support CIFS authentication, as
it requires an MD5 password hash exchange, it would rule out use of the CIFS server for
all users and the CIFS server would be disabled.
Alternatively you could instead supplement the existing capabilities of alfrescoNtlm by
inserting an ldap instance before or after alfrescoNtlm in the chain. This means that
you could use the built in accounts alongside those accounts in the directory server.
Furthermore, the built in accounts could access Alfresco through the CIFS server, since
alfrescoNtlm is able to drive CIFS authentication.
In this scenario, where you chose to position your ldap instance in the chain determines
how overlaps or collisions between user accounts are resolved. If an admin account
existed in both Alfresco and openLDAP, then admin would be Alfresco if alfrescoNtlm
came first, or openLDAP if the ldap instance came first. For this lab we recommend that
you position ldap first.
1. Make the other necessary changes to the alfresco-global.properties file,
using the following information:
• LDAP server: localhost
• Port: 389
• User name format: uid=%s,ou=People,dc=alfresco,dc=com
• Authentication: simple
• Principal account: cn=admin,dc=greenenergy,dc=com
• Principal password: alfresco
19. Lab - LDAP configuration
Authentication 19
• DN for groups: ou=Groups,dc=greenenergy,dc=com
• DN for users: ou=People,dc=greenenergy,dc=com
• This file is found in the directory: /opt/tomcat/shared/classes/
(Double clicking the file will invoke the text editor.)
2. You can inspect the LDAP directory using Apache Directory Studio.
3. Restart the Alfresco server.
4. Test your changes:
• Look in the log file for any errors related to the authentication subsystem.
• Login as admin and see if the users have been created in Alfresco.
• Login as one of the new users.
20. Authentication
20 Alfresco Elements
Authentication
Lab review
Having completed this lab you will have a system which uses an LDAP server for authentication.
Since the authentication chain now provides a user registry, the synchronization subsystem has
some work to do when Alfresco starts up.
The first thing that you may have noticed when you looked at the log file is that the
synchronization subsystem reports that it created 3 users. In doing this is has used attributes
such as email address and group memberships retrieved from the OpenLDAP server through an
LDAP query.
The synchronization subsystem uses an incremental timestamp-based synchronization strategy,
meaning that it only queries for changes since the last synchronization run. So after the first
start up, further synchronization runs can be almost instantaneous. Additional synchronization
runs are triggered by a scheduled nightly job, however whenever an unknown user successfully
authenticates you will find that their entry is created in Alfresco which means that users should
stay synchronized with hardly any effort.
If you navigate to a user profile, notice that attributes such as email address are populated
automatically from Active Directory. It is not possible to edit or alter this information if the user is
authenticated through an external system.
Authentication troubleshooting
Setting up a complex authentication regime is probably one of the most challenging tasks you
will face as an Alfresco administrator. Therefore knowledge of some trouble shooting is helpful.
Troubleshooting an installation is all very well, but if you plan out how your authentication will
work up front you will be in a much stronger position. This is the key to success plan your
work out before you start, know what you are trying to achieve and make sure all the separate
components work individually before tempting to bring them all together. If you are facing
difficulties with your setup there are a number of useful tools you can use, all of these tools are
either open source or free to use.
21. Authentication
Authentication 21
To trace the protocol communication between the client and server you can use Wireshark, this
lets you see the protocol communications between multiple machines and can be useful in a
variety of cases. If you are using an openLDAP directory you really must have a GUI tool, such as
ApacheDirectoryStudio, to help you see the structure of your LDAP repository.
If you are using Active Directory two tools come in particularly useful. The first is ADSI Edit, this
is a Microsoft tool which forms part of the Windows Support Tools. These tools are not installed
with the Windows operating system and must be separately installed. They are located on the
Windows Installation CD, Support folder, Tools subfolder. They can also be downloaded from
Microsoft Download Center. This very useful tool lets you view and navigate Active Directory as
if it where an LDAP repository, it can show you the equivalent property names in LDAP for the
Active Directory properties, something which is sometimes not very obvious.
The final tool AdFind is useful for running the queries which you embedded in your alfresco-
global.properties file directly against the Active Directory server and returned result
set, this allows you to modify your LDAP query before embedding it into the alfresco-
global.properties file.
Summary
This module has examined the authentication implementation of Alfresco. You have witnessed
the authentication methods available to you, understood the components of an authentication
subsystem and configured Alfresco to utilize remote authentication.
