Active Directory Issues

[onovotny]

I found a small bug in the active directory code --

In the server options where it asks for an AD Domain, it won't accept the full DNS name.

Originally I tried ntdomain.mydomain.com, and that wouldn't work. When I switched it to simply ntdomain (the netbios domain name), it worked.

Can this be documented somewhere or fixed so that either works?

Also, it'd be nice if UPN's were supported so that I can login as user@mydomain.com (since I have mydomain.com configured as a UPN in my AD Forrest). That way it can authenticate against multiple domains depending on which one the user is in.

Regards,
--Oren

[jeremy_sg]

Thanks for pointing that out. We want to keep things simple with AD password management right now, thus the caveats that all users authenticate against the same domain, and all AD usernames match the vault username.

[onovotny]

Since the AD username/password is being sent over the net, can the AD integration require (or at the very least strongly warn) that SSL should be mandatory for the virtual directory in IIS?

[jeremy_sg]

When the Vault client or admin tool or api send a password, it's encrypted with a one-time key which is also encrypted. Vault never sends a plain password. I want to be very clear in stating that although Vault sends the AD password, it is as safe as SSL. We've had encrypted passwords since 1.0, and wouldn't have added AD passwords in Vault if we sent them in plain text.

[onovotny]

That's good to hear

Is there any more info that you can point to that describes the security mechanisms of Vault; I don't recall seeing any info that describes the cryptographic mechanisms that vault uses.

Thanks!

[jeremy_sg]

Because it's not a user-visible feature, we haven't really put a lot of effort into telling people how the password is encrypted. The password is the only bit of information that we go out of our way to protect in regular HTTP connections. We still recommend that security-consious customers use SSL.

[onovotny]

Okay, thanks!

--Oren