Security in a complex environment is complex. However, a really secure system should not impact the user. It must be easy to use or else the users will find a workaround. A scenario I have frequently noticed at bank branches. Roles are defined to different users. Usually, the person entering the data does not have the rights to verify and approve the transaction. While this is desirable and necessary, what is an employee to do if a client is in front of her and the approver is not available. I have seen the staff member sign in as the approver and clear the transaction.

The approver trusts the person at the counter but the system does not! People find an informal solution to get the job done rather than fight the system. A far better option would be to let the approver delegate authority. This requires a more complex mechanism for authentication but the system would enable users to work as the security policy of the organisation expects them to work.

Another irritant that can occur is if there are many applications and on many servers, whether physical or in the cloud, the easiest option appears to be to let the users create multiple identities or, at least, passwords. A user may then write passwords on a piece of paper to keep track of his/her various accounts or may use the same password on every system. In the latter case, the weakest system in the organisation's network can be used as a break-in point. This is almost inevitable as a developer and an administrator are not going to make the effort to secure a relatively insignificant application. I have often seen clear text passwords for such applications. It is highly likely that at least some of the users will use the same password for this application as they have used for the secure applications of the organisation. It creates an opportunity waiting to be exploited.

An obvious solution is to use a directory server for authentication. OpenLDAP is the common solution for the Linux and Unix environments. Replacing is password file authentication by LDAP is not difficult and a suitable tutorial can be easily found for each distribution.

Routers and various server applications can use the same LDAP server for authentication and access rights for network, applications and roles.

Unfortunately, one group of systems just refuse to merge with the LDAP environment – the Microsoft Windows environments. Windows servers will want to use Active Directory servers, which extend LDAP servers.

It is possible to configure an Active Directory server so that it can be used as an LDAP server for Linux authentication needs. We can't wish it away – even gentoo has a wiki page explaining how to do so (http://en.gentoo-wiki.com/wiki/Active_Directory_Authentication_using_LDAP ). However, some people may be reluctant to use Windows environment for all their authentication needs.

Samba 4, currently in beta will have the capability of being an Active Directory server, and will, thus, be usable for all applications, regardless of whether Linux or Windows or dedicated hardware like routers. You can read more about it at http://wiki.samba.org/index.php/Samba4/HOWTO.

In the current environment, there is no getting around keeping two directory servers – one for windows authentication and one for everything else. Given that constraint, one could use both an LDAP server and Active Directory server but synchronize the two.

The 389 directory server from Fedora includes the option to sync with Active Directory – http://directory.fedoraproject.org/wiki/Howto:WindowsSync.

A similar functionality is not available in OpenLDAP, which is the more popular option. So, one needs to look at alternative extensions. An example is http://acctsync.sourceforge.net/ which though has been inactive for a number of years. Once the synchronisation of accounts works, updates are not really needed. However, there is one more and active alternative – http://lsc-project.org/, whose goal is broader:

Open source connector to synchronize identities to a LDAP directory from any data source including any database with a JDBC connector, another LDAP server or flat files ...

This project will use a configuration file to write changes from the OpenLDAP server to the Active Directory server. This option is an acceptable solution if one wants to set the password only using the Linux environment and have these changes migrate to the Active Directory server.

Password can be written to the Active Directory provided it can be sent in clear text. This imposes the constraint that LDAP must store it in clear text or in a two way encryption scheme. So, the password cannot be stored as a MD5 or SHA hashed string in the LDAP server.

This constraint raises issues of trust. In fact the best solution is based on trust. An excellent resource is “PIG: Practical Interoperability Guide” - http://pig.made-it.com/. Active Directory uses Kerberos. Linux and OpenLDAP can use Kerberos authentication. Although Microsoft's implementation of Kerberos is not identical to that of MIT Kerberos, it can be set up to trust a MIT Kerberos server as well. Hence, it is possible to keep the password store in a MIT Kerberos server which is used by both the Windows and Linux environments (http://pig.made-it.com/kerberos.html).

Finally, projects like FreeIPA http://freeipa.org/ make it easier to manage the whole set up, including selective delegation of administration rights so that.

Tragedy is that every organisation's infrastructure starts small and all this complexity seems unnecessary. Each little addition to the infrastructure is a small increment. After a while, it is too huge an effort to change. The same practices continue until a disruptive change is forced on the organisation. Instead, it is desirable that systems administrators think about the best practices for access controls and implement them early before the need becomes apparent. Even if the organisation does not expand, at least the skill set of the systems administrators would have grown!