Elements_Authentication.pdf
0 likes469 views
- Alfresco can authenticate users internally or externally against directories like Active Directory. It supports single sign-on so users only need one set of credentials. - The document discusses configuring Alfresco for Active Directory authentication with single sign-on by setting up an LDAP authentication subsystem and chaining it with the internal subsystem. This allows users to authenticate against Active Directory and sign into Alfresco automatically with their Windows credentials. - Synchronizing user data from Active Directory to Alfresco using the synchronization feature ensures users exist in Alfresco before they try to access it.
Elements_Authentication.pdf
- 2. 2 Alfresco Elements Contents Document information.............................................................................................................. 3 Authentication............................................................................................................................4 Lab - LDAP configuration.......................................................................................................17 Authentication..........................................................................................................................20
- 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.