I have an environment where company employees have accounts in a parent domain and outside contractors (often off-shore) have accounts in a child domain. The child domain has a one-way trust with the parent domain (i.e. parent accounts can authenticate in the child domain, but child accounts can't "get to" the parent domain). My Vault application server (v3.0.6) and SQL server both exist in the child domain.
Up to now, all Vault users have been AD authenticated and members of the parent domain. I just added two new accounts within the child domain, and when I try to use those accounts to log into the Vault server with the Vault client, it can't authenticate them (even if I specify the username as either "child\account" or "account@child.parent.com").
I think the problem is that the vault.config specifies :
<ActiveDirectoryDomain>ParentDomainName</ActiveDirectoryDomain>
Is there a way to either specify multiple <ActiveDirectoryDomain> values or, perhaps, to force/allow the domain to be passed as part of the username?
Tony
Multiple <ActiveDirectoryDomain> nodes in vault.config
Moderator: SourceGear
Thanks for the feedback. I'll see what I can do as a work-around.
Is there a standard way for me to submit this type of feature request for future consideration?
I would really like to see the <ActiveDirectoryDomain> node become a collection of nodes, where the server would try to authenticate you against each in the order provided, until it found one that succeeded (or failed).
Or, optionally, if you could set this node to an "empty" value, which would tell the service that the user name provided by the client should/would have a domain attached (either in the format of domain\account or account@domain.com).
A third option might be to allow the <ActiveDirectoryDomain> value to be set to a "default" domain value, but allow the client user to optionally provide the domain for their account (so in my situation, I could omit the domain during login and the server would default to "parent" but some users would put in an account name like child\user or user@child.parent.com).
Just some thoughts. Thanks again!
Tony
Is there a standard way for me to submit this type of feature request for future consideration?
I would really like to see the <ActiveDirectoryDomain> node become a collection of nodes, where the server would try to authenticate you against each in the order provided, until it found one that succeeded (or failed).
Or, optionally, if you could set this node to an "empty" value, which would tell the service that the user name provided by the client should/would have a domain attached (either in the format of domain\account or account@domain.com).
A third option might be to allow the <ActiveDirectoryDomain> value to be set to a "default" domain value, but allow the client user to optionally provide the domain for their account (so in my situation, I could omit the domain during login and the server would default to "parent" but some users would put in an account name like child\user or user@child.parent.com).
Just some thoughts. Thanks again!
Tony
FYI ...
In the interrum, the only reasonable solution for us was to create the AD accounts in the child domain (for security purposes) and then configure Vault *not* to use the AD for authenticating those particular accounts. We disabled the user's ability to change their AD password and made the Vault account information the same as the AD account information (since we only allow SSL access, the security risk is minimal).
I still think (strongly) that this is an area that could be enhanced in the product. Multi-domain networks are very common today and this was a surprising limitation.
Thanks again for your help. And don't get me wrong, I really like this product!
Tony
In the interrum, the only reasonable solution for us was to create the AD accounts in the child domain (for security purposes) and then configure Vault *not* to use the AD for authenticating those particular accounts. We disabled the user's ability to change their AD password and made the Vault account information the same as the AD account information (since we only allow SSL access, the security risk is minimal).
I still think (strongly) that this is an area that could be enhanced in the product. Multi-domain networks are very common today and this was a surprising limitation.
Thanks again for your help. And don't get me wrong, I really like this product!
Tony