I hate passwords. Heck, I have 6 passwords to do my daily work, and they all have different restrictions and renewal intervals. Any way to reduce this is a benefit to my daily work — reducing the “friction” of doing my daily work — and gets me through my day. VirtualWisdom has it’s own passwords, but can authenticate a user via Kerberos to put those passwords somewhere else. Kerberos can be backed by LDAP (posixUser), Active Directory (with its own schema), or other authorities. Configuring an old technology like Kerberos tends to be mired in issues that were conventions, are now constraints on some platforms, and in some cases “Everyone knows about that” except that not everyone knows the same “that”.
If you’ve read my content here on our Virtual Instruments SAN Best Practices blog, you’d see that it tends to be of a how-to nature. In this article, I’d like to help provide an easy-to-find reference to accelerate configuring your Active Directory authentication via your Kerberos client on VirtualWisdom.
Kerberos is a relatively old technology that is (apparently) still under active development by MIT. VirtualWisdom uses it only to ensure that a user is who they say they are: “Is this really Allan Clark?”. Note that it doesn’t say whether the user is an administrator, Dashboard-only user, etc; it only ensures that I really am me, and you really are you. Kerberos users — often referred to as LDAP or Active Directory users — still need to have an existing profile pre-defined in the VirtualWisdom platform.
Some users manually edit the “\VirtualWisdomData\Users\users.xml” file to bulk-add users, but this requires a service-restart and risks human-error.
In general, Kerberos requires a few things:
The output of a “set” command in your Windows command shell can probably tell you everything you need to know (for example, suppose I log in as “SC14\allan.clark” and my organization is “vi.com”):
USERNAMEto uppercase (i.e. ALLAN.CLARK, but not SC14\ALLAN.CLARK)
LOGONSERVERto uppercase or use its IP address (i.e.:
192.168.1.1— don’t keep the “\\”, but add the domain such as “vi.com” if necessary)
SC14.VI.COM” — uppercase, and the domain “vi.com” is there)
Once the new user is saved, you can log in. For example, I would type “ALLAN.CLARK” as my login, and use my Active Directory password as my password. When AD forces me to change my password, the new password is immediately available to VirtualWisdom because it’s not stored on the server, VirtualWisdom checks every time I login.
As noted above, conventions can become rules: although Kerberos is case-sensitive, MIT recommends we canonicalize by converting to uppercase; Microsoft has that as a rule, but VirtualWisdom preserves flexibility. Both approaches have obvious merit, but due to this difference, you’ll need to login using uppercase letters for your username (but both upper- and lowercase for your password).
Be aware: if the time on your VirtualWisdom server skews too far away from your AD server’s time, you’ll have login failures. I would recommend either frequently checking Windows Time Service or use Network Time Protocol to enforce time accuracy.
If there are any problems at all, we can very quickly help you in a web session shorter than an hour. In VI Services, we have a tool “VICT” (VICT.JAR, VICT.BAT) which, if run on your server with the –kerberos option, will do these calculations for you. Even if running java is not within your comfort zone — or security policies — that’s absolutely fine, it’s just a few seconds longer to read the “set” output. Simply contact your Regional Sales Manager, Solutions Consultant, or Services-Delivery Manager to start the process.