Please note that this solution is very non-invasive to your AD configuration! It doesn't require any changes to your AD server (except for requirements like the CA role). It will not affect any users at all until they request an OTP from the WiKID server, which triggers their password to be overwritten. To 'remove' a user, just change their password manually.
WiKID's Active Directory protocol writes the one-time passcode to AD as the new password. You create an Admin in AD for WiKID that is able to change users' passwords. Then, when the user requests an OTP for an AD-enabled WiKID domain, your WiKID server pushes the OTP to AD as the new password. If the WiKID domain is configured for password reset, then the user is prompted to change their AD password on login. If not, then the user logs in with their OTP and once the OTP expires, WiKID overwrites the OTP in AD with a random long string.
Our goal is to reduce the costs of static passwords by enabling resets using two-factor authentication instead of help desk calls and to increase security by replacing static administrator - Domain admins as well as Local Admins - with dynamic one-time passcodes. This document shows you how to configure these options. (Remember that WiKID uses the term Domain as does MS for Windows domains, but they are separate and distinct.)
There's very little to do on Windows or AD. Except that you must have a certificate authority and an issued certifcate for your AD server as the WiKID server will make SSL-encrypted LDAP call. The WiKID server will grab the client cert without any help, but it needs the cert to be there. You can use a self-signed cert from the CA role on AD - the only requrement is that the cert be acceptable to AD.
Enable the protocol
On the WiKID server, on the Configuration tab, click on Enable Protocols.
Click on Active Directory and Enable it.
Create a WiKID domain for Active Directory
Once it is enabled, click on the Domains tab and then Create a new domain. You will see some additional options at the bottom of the Create domain form.
The first box, Use Active Directory, specifies that this domain uses the AD protocol. If you have a domain that uses RADIUS for a VPN or other solution, you need another domain for AD, similar to the way TACACS+ works in WiKID. This also means that you need new licenses for AD domain users.
The second box specifies that this is a password reset domain. If checked, the server sends the "User must change password at next login" flag to AD. The user logs in with their passcode and must re-set their password.
The third box, if checked, specifies the use of passwords designed to meet AD's complexity requirements. The generated passcodes will be all caps and won't use all the letters, but will be 8 characters long and have a non-alpha numeric character. We do this to avoid font confusion around characters like l and 1 and 0 and O as they might be displayed on a mobile device. If you do not choose the enable this, you must remove password complexity requirement in AD. This might make sense in some scenarios. In the non-password -reset scenario, the OTP is only good for a limited time and then it is over-written. You could use an internal IP for the server code and require smartphone tokens, meaning the phones had to be on the local network.
Obviously the WiKID server needs to communicate with a domain controller. The last four boxes provide this information.
NB: As of Java 1.8u51 and 1.7.0_85 or higher, you must now use a hostname and not an IP address. You can also create an entry in /etc/hosts.
Here's what a configured domain looks like:
This one is configured for an internal IP for the server code, it allows all token types and uses complex OTPs to replace static passwords. We created an administrator called 'wikid admin' in AD with the power to reset users' passwords.
Companies have different ways of managing administrators in AD. Microsoft has best practices for managing Admin accounts. Obviously, it is best to separate user and admin accounts etc. But a WiKID user can have multiple tokens (on the same license) so note that all of these tokens would be a single license:
Each device ID is unique and you can add a username in the notes for each one. Not recommended, but possible. If you currently share passwords using a password manager or spreadsheet, this is a big step up.
Password help desk calls are quite expensive for the typical company and whether automated or manual, a target for social engineers. Once attackers are on your network, they need administrative credentials to escalate their attack. We hope that WiKID's native Active Directory two-factor authentication will help reduces costs and increase security.
