In the AD Authentication topic it is said that to authenticate, you have to supply a password in the JSON body of the request, or otherwise if you use the API. Is there a way to authenticate with AD without requiring the programer to know the password of the account. I was thinking of calling AD somehow to get an authenticated token, which I would transmit to Vault to authenticate to AD. Is that possible? This would allow SysAdmins to change the passwords on accounts on the fly.
Could you elaborate on your scenario some more? I’m not quite sure what you’re after/what your end goal is.
Regardless, to log into Vault via LDAP you must provide a user name and password. Other authentication methods, such as OIDC can leverage SSO.
If you need a method for devs/admins to retrieve a short lived credential from Active Directory then the AD or OpenLDAP secrets engines may be what you’re after (the secrets engines handle credential rotation differently - there’s a total of 4 different methods between the 2 engines, the docs should provide a good overview but if needed I can break it down more for you).
Yes, let me re-phrase. We want to run a robot processing automation (RPA) in which each robot (BOT) is given an account in AD (Windows). We would want a SysAdmin to have the ability to rotate these passwords every now and then without impacting script developers. Developers generate scripts that need to access a database. For that we can use the SQL Server database plug-in with password rotation. But the problem now is that anyone can call Vault and get temporary database credentials to read and write to the datbase. So we need Vault to authenticate callers, and allow only the bots. To do that, we use AD authentication, and this is fine. But to authenticate to Vault, you nee to transmit a password. So somehow, the BOT must use his own password. That would be fine, but it runs aground the previous wish that a SysAdmin may rotate the password freely, because the BOTS somehow have to know their own password in some sort of file, where it may be seen by script developers. Considering that BOTS already run in their Windows account, which is configured by the SysAdmin when the password are rotated, the BOT could (theoretically) ask a token from its AD principal to vouch for its identity (that would not expose the password), and transmit the token to Vault for authentication in AD.
I also considered the AD-Database Plugin, but then the problem is the same: to make sure only BOTS can access the AD-Database Plugin, you have to authenticate then with AD, and that requires password transmission, right?
Does that explain my case better?
Yes, this helps, thank you!
Are the bots run from specific machines/instances or can they be run from any developer’s machine?
I’m assuming you’ve also looked at the Kerberos auth method? (I don’t have any experience with it yet but it’s something I’m interested in exploring at some point). This might get you closer to what you’re after but I’m not certain on that.
The BOTs are run from specific instances.
Are the instances hosted in VMWare, AWS, GCP, Azure, etc.?
Windows desktops VMs on Citrix. I will inquire about Kerberos.
Yea, I’m not entirely sure how I’d go about solving this one. If Kerberos doesn’t seem like it would fit your needs then you’ll probably have to add a layer or two to mitigate any weak points in your chosen solution.
Another option you could look into would be Response Wrapping. Basically you could have a trusted orchestration process make the credential request on your behalf and then “wrap” those credentials via a one-time-use token. The orchestration tool could then drop the token on the target VM for use by the bot. This would require a bit more configuration but might also mitigate some shortcomings of other solutions. These one-time-use tokens can also be time-bound (e.g. live for 15 minutes and then no longer usable) and can also be restricted by IP/CIDR range so they can only be used by the target system.
Would it to be possible to use user-certificates to have the bots login rather than a username/password to authenticate? That would remove the requirement of a password completely and unless otherwise needed the accounts could be locked.
Aram, thanks for the input. For the time being I am still investigating Kerberos. I have to counter-check with our AD settings, and if it fits, I believe Kerberos could do exactly what I had in mind. I will investigate certificates afterwards. Thanks for the input.
I’ve looked down this road recently, so I’ll publish my findings.
This is doable, but the Vault client executable isn’t Windows-aware, so it cannot use existing Kerberos tickets in its environment, it can’t piggyback on the SSPI. You would need to generate keytab files for the service account(s) and have them where the vault client can read them. Those keytab files will need to be updated when the password for the service account changes.