I wanted to put in a request for Vault to support Windows Domain Accounts and groups in addition to the existing mechanism.
It could be a minor modification to the existing security infrastructure. Accounts and Groups could still be created in Vault as is currently done, but there could be an option to link them to a Windows account/group.
It'd be far easier to maintain a single set of credentials rather than one per app (yada, yada, insert typical SSO arguments here).
For vault clients that are running from a machine logged into the domain, it can use the currently logged in ID. For machines not on the domain, they can provide a domain username/password that can then be authenticated by the server.
Our developers already have a windows account to access SharePoint; I'd like to be able to link up SharePoint with Vault too, and having a unified user-base would be a plus.
Thanks,
--Oren
Feature Request: Domain Account support
Moderator: SourceGear
Oren,
Vault 2.1 will allow users to use their domain password to authenticate with Vault. There are some things to note:<ul><li>The Vault admin will still need to manually create each user account. The Vault username must match the Active Directory username.
<li>Vault only asks Active Directory to authenticate the user. Vault doesn't check any properties of the user's AD object.
<li>The Vault admin can specify which users authenticate against AD and which ones do not.
<li>All users must authenticate against the same domain. The domain to authenticate against is configured in the Vault Admin tool.
<li>There will be no special handling on the client side to automatically log the user in if they're already authenticated against the domain. The user will still have to type in his password or use a login profile.
<li>Groups are still configured only by the Vault admin tool and are not checked against AD.
<li>Security rights are still configured only by the Vault admin tool and are not checked against AD.
</ul>
Vault 2.1 will allow users to use their domain password to authenticate with Vault. There are some things to note:<ul><li>The Vault admin will still need to manually create each user account. The Vault username must match the Active Directory username.
<li>Vault only asks Active Directory to authenticate the user. Vault doesn't check any properties of the user's AD object.
<li>The Vault admin can specify which users authenticate against AD and which ones do not.
<li>All users must authenticate against the same domain. The domain to authenticate against is configured in the Vault Admin tool.
<li>There will be no special handling on the client side to automatically log the user in if they're already authenticated against the domain. The user will still have to type in his password or use a login profile.
<li>Groups are still configured only by the Vault admin tool and are not checked against AD.
<li>Security rights are still configured only by the Vault admin tool and are not checked against AD.
</ul>
-
Sven Aelterman
AD integration
So, the only thing that will happen is that the password will be managed by AD?
I would suggest that automatic login (as in VSS) would be a great option to be added in a later release. Then add impersonation, and admins could configure security options based on their AD users (i.e. db access, web access, etc.)
Without automatic logon, I am not sure how useful "AD integration" will be...
I hope the team would take this into consideration for future releases.
Thanks,
Sven.
I would suggest that automatic login (as in VSS) would be a great option to be added in a later release. Then add impersonation, and admins could configure security options based on their AD users (i.e. db access, web access, etc.)
Without automatic logon, I am not sure how useful "AD integration" will be...
I hope the team would take this into consideration for future releases.
Thanks,
Sven.
Automatic login can still be accomplished, using profiles (you can set up an auto-login in 2.0 by creating a profile and checking the "Automatically connect using this profile" checkbox).
The main benefit af using the Active Directory password control is to provide a way for network admins to specify how tough the password must be (numbers, punctuation, mixed case, etc), and to specify a password expiration period.
Vault's security assignments and roles are so specific to Vault, that it doesn't make any sense to store them in Active Directory.
We've considered creating a tool that would allow the Vault admin to "import" users from Active Directory.
The main benefit af using the Active Directory password control is to provide a way for network admins to specify how tough the password must be (numbers, punctuation, mixed case, etc), and to specify a password expiration period.
Vault's security assignments and roles are so specific to Vault, that it doesn't make any sense to store them in Active Directory.
We've considered creating a tool that would allow the Vault admin to "import" users from Active Directory.
-
Lovalvob
Thanks for this. It's a small improvement, but welcome.
May I suggest, however, that you consider RADIUS authentication instead. If you're not going to fully integrate with IIS/.NET security, you might as well go with an industry standard. It's easier to implement, and I'd bet that most of us who care about integrated security have RADIUS running anyway.
On the other hand, since you're doing an AD check, will this finally provide the ability to secure the Web Service, itself, using NT security? I'm sure that you've thought a lot about security in the Vault Server, but I'd feel a lot better if I had all of the standard resources of IIS/.NET at my disposal.
And finally, but only peripherally related. I've yet to successfully change the path for the vault server. Since I can't really secure it, I'd like it to be deep and obscure, instead of public and standard. Have I missed something?
May I suggest, however, that you consider RADIUS authentication instead. If you're not going to fully integrate with IIS/.NET security, you might as well go with an industry standard. It's easier to implement, and I'd bet that most of us who care about integrated security have RADIUS running anyway.
On the other hand, since you're doing an AD check, will this finally provide the ability to secure the Web Service, itself, using NT security? I'm sure that you've thought a lot about security in the Vault Server, but I'd feel a lot better if I had all of the standard resources of IIS/.NET at my disposal.
And finally, but only peripherally related. I've yet to successfully change the path for the vault server. Since I can't really secure it, I'd like it to be deep and obscure, instead of public and standard. Have I missed something?
A little off topic here -
If I remember correctly, the Vault server can be configured to deny only but a couple of users by using the standard Windows security settings built into ASP.Net and web.config.
Since this ties Vault to the currently logged in user, it isn't as robust as something like Radius, but does provide limited security if Vault is used within the same Domain or within trusted Domains.
If I remember correctly, the Vault server can be configured to deny only but a couple of users by using the standard Windows security settings built into ASP.Net and web.config.
Since this ties Vault to the currently logged in user, it isn't as robust as something like Radius, but does provide limited security if Vault is used within the same Domain or within trusted Domains.
Jeff Clausius
SourceGear
SourceGear
My next goal for securing Vault is to implement client-side certificates so that IIS will reject any user that doesn't present a cert that was issued by IIS. This won't make it in to 2.1, but I would like to see it soon. In my mind, that's a better access control than having IIS demand that users be AD authenticated, and will work over the internet as well.