Home

Secure Authentication with CryptID

CryptID will be standardised for clients using Microsoft AD and OpenLdap services, but could also be extended to support other ldap server variants - as long as the ldap variant can sync to an OpenLdap server. In short, there is no doubt that full synchronisation between a pure open standards compliant ldap source and the CryptID platform is possible. Some instances might require a bit of tweaking on a client to client basis, but without too much hassle a pure and generic ldap implementation is relatively easy.

A more challenging issue is how to get accounts and passwords out of Active Directory servers. Even if it was possible to extract the user account information out of AD (quite easy when using OpenLdap client tools) and provision it, AD doesn't make it possible to extract passwords from ldap. In fact, AD stores the password in a proprietary hidden, non reversible one way hash - so even if you could view the password (and you can't), there is no way you could extract it and reuse it in another database. Provisioning authentication capable accounts from AD is critical in order to make the CryptID experience a reality, but how?

Getting Passwords From AD

Let's assume you have already synchronised all of your user accounts into CryptID's directory using available LDAP search tools. You still don't have any of your passwords at this stage, but this is resolved by CryptID service, using a simple authentication relay technique...

stage 1:
Use a shell script or sync tool of choice against the AD server to pull accounts into CryptID. These accounts would be pure LDAP accounts with CryptID schema loaded, stripped of all AD information. The user has yet to log on for the first time to an application that authenticates to the CryptID authentication server.

stage 2:
When the user logs on for the first time, he will supply his application with his logon and password for access - for the sake of this demonstration, let's asume his application is an Apache web service. The Apache server will pass the username and password supplied by the user to CryptID. The CryptID will check the password against it's locally stored user account to see if it matches. If the password matches, then the user is authorised to access the application. If the password fails, then CryptID will attempt to authenticate using the real client login + password against the original account server over LDAP. If the original server validates the login, then the password is stored in CryptID's database for future service authentication. If the original server rejects the logon credentials relayed by the CryptID, then authentication to the requesting service is denied. When the clients password changes on the AD server and he attempts to authenticate again, CryptID again steps through the validation callback process. For this to work, access must be allowed between CryptID and the Global Catalog port on the client Active Directory server, which for security reasons takes place over an encrypted connection.

Road Map Ahead
CryptID is currently in proof of concept stage, but in future releases local hashed password storage will be replaced by pasphrase unlocked Certificates. This will allow for CryptID to meet more enterprise class security requirements by providing authentication without exposing passwords in the CryptID database. Additionally, CryptID will support pushed password synchronization, thereby doing away with the need for opening up LDAP ports for CryptID validation.