RFD 210: HSM support in Active Directory environments#54223
Conversation
| ## Why | ||
|
|
||
| Teleport supports certificate-based login in Active Directory environments for | ||
| both Windows desktop access (RDP), and MS SQL database access. |
There was a problem hiding this comment.
Now we also have Oracle, but it uses the same code under the hood.
| For database access, our setup instructions require that users generate the CRL | ||
| with `tctl auth crl`, copy it over to the Windows environment, and publish it to | ||
| LDAP using `certutil -dspublish`. | ||
|
|
||
| It is worth noting that `tctl auth crl` generates empty CRLs that are valid for _1 year_, | ||
| so database access will require manual intervention in case: | ||
|
|
||
| - the CRL expires after 1 year | ||
| - a CA rotation is performed |
There was a problem hiding this comment.
We could improve the UX here quite a lot by using the automated publishing workflow. We should probably keep the tctl auth crl as a fallback.
We will likely need an active LDAP connectivity anyway to lookup SID for username in order to fix #53502.
There was a problem hiding this comment.
Going to keep that out of scope for now, since getting HMS to work is priority over other UX improvements. Feel free to file a new issue and link to this RFD for book-keeping.
There was a problem hiding this comment.
Oh sure, this was just a side remark, no need to change this RFD.
|
|
||
| ### Audit Events | ||
|
|
||
| TODO: update cert.create event with signer SKID? |
There was a problem hiding this comment.
This would be very helpful indeed. The current cert.create events don't mention which CA/auth server did the signing. Either SKID or auth server ID would be helpful to distinguish things.
probakowski
force-pushed
the
rfd/0210-windows-ad-hsm
branch
from
3093cf2 to
8ed6c78
Compare
probakowski
force-pushed
the
rfd/0210-windows-ad-hsm
branch
from
8ed6c78 to
946cd49
Compare
probakowski
added
rfd
|
|
||
| ## Required Approvers | ||
|
|
||
| * Engineering: @nklaassen && (@gabrielcorado || @greedy52) |
There was a problem hiding this comment.
| * Engineering: @nklaassen && (@gabrielcorado || @greedy52) | |
| * Engineering: @nklaassen && (@gabrielcorado || @Tener ) |
Krzysztof already approved from db side.
| procedure very similar to what they already do, they will only have to repeat | ||
| the `certutil -dspublish` command once for each individual CRL. | ||
|
|
||
| TODO: in order to publish to auth server, the CN of the CRL would need to change. |
|
|
||
| TODO: in order to publish to auth server, the CN of the CRL would need to change. | ||
|
|
||
| #### Publishing: add CRLs to the backend `certificate_authority` |
There was a problem hiding this comment.
I would just like to see some description of when the auth server generates the CRLs and adds them to the certificate_authority in this design
maybe on auth startup the auth checks each key in each CA that needs CRLs. if it can sign with that key, and there is currently no CRL or the CRL expires in <1 year, it generates a new one and updates the CA in the backend. this will handle adding CRLs to existing CAs without them, and refreshing them semi-regularly
during CA rotation when generating new keys it should also generate and store the CRL
not sure if we'd want to also periodically check/refresh the CRLs or if just at auth startup is enough
zmb3
force-pushed
the
rfd/0210-windows-ad-hsm
branch
from
dfd994f to
76f4be5
Compare
public-teleport-github-review-bot
bot
removed request for
atburke,
fspmarshall and
gabrielcorado
Pull Request is not mergeable
7 participants
No description provided.