[SERVER-46292] Add support for kerberos style gMSA extensions Created: 21/Feb/20 Updated: 09/Aug/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 4.2.3 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Luke Prochazka | Assignee: | Backlog - Security Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Server Security
|
| Participants: | |
| Case: | (copied to CRM) |
| Description |
|
This is a feature request to enhance the existing Kerberos capabilities to include the gMSA authentication API. Specifically this is an evolution to the use of SPNs and machine accounts created by Microsoft, and is Windows proprietary. |
| Comments |
| Comment by Spencer Jackson [ 11/Mar/20 ] |
|
It appears that gMSA accounts have credentials which authorized principals can obtain via GetServiceAccountPassword. SSPs, such as the Kerberos implementation of SSPI, should invoke GetServiceAccountPassword from inside of InitializeSecurityContext or AcceptSecurityContext. It appears consumers of this functionality must have the "TCB privilege" or be a network service. It appears that SSPI is expected to work normally with credentials provided by this mechanism, but configuration and deployment of Active Directory in this mode, in order to validate this fact, looks deeply non-trivial. I expect that the act of setting up an environment with gMSA enabled will be very time consuming. |