Not possible to obtain access token (PAC) for authenticated context, unsupported operation

[kvv81]

We need to obtain detailed security information about authenticated user via GSSAPI.
As the part of NETLOGON_VALIDATION_SAM_INFO4 structure (response to NETLOGON_NETWORK_INFO from DC, part of processing AUTHENTICATE_MESSAGE from client by server, see [MS-APDS], "4.1 NTLM Pass-Through Authentication" for example) all the details of authenticated user are delivered to server. We need this from server side (after a call to gss_accept_sec_context) to identify the user (userSID, SIDs of all groups, etc).
It seems like gssntlmssp library doesn't have this option yet ("The operation or option is not
available or unsupported" is returned for gss_get_name_attribute for example). Can we add it as a new feature?

Possible ways to inquire this information from the context via GSSAPI are:

• gss_get_name_attribute with "urn:mspac:" name (also can get sub-parts, like "urn:mspac:logon-info")

• gss_inquire_sec_context_by_oid with EXTRACT_PAC_AUTHZ_DATA_FROM_SEC_CONTEXT_OID

See gssapi_pac.c code of samba for usage example: https://github.com/encukou/samba/blob/master/auth/kerberos/gssapi_pac.c
Also opencifs LsaMapSecurityGetPacInfoFromGssContext here: https://github.com/BeyondTrust/pbis-open/blob/master/lsass/interop/lwmapsecurity/lwmapsecurity-lsass.c

[simo5]

The only problem I see in using things like EXTRACT_PAC_AUTHZ_DATA_FROM_SEC_CONTEXT_OID is that we do not get a MS-PAC from a NTLM negotiation.

The MS-PAC is attached to a kerberos ticket by the KDC and that's why GSSAPI/Krb5 can offer it.

In most cases that info is synthesizes on Windows via a number side calls to the LSASS subsystem and RPCs to a Windows DC (for non local accounts).

I would be open to add interfaces to pull that information out when gssntlmssp is used in conjunction to Winbindd on a samba managed machine though.

Se the current Winbindd backend as an example of how to interface there.

[kvv81]

Yes, you are right, MS-PAC is slightly different than NETLOGON_VALIDATION_SAM_INFO4 structure and reporting proper PAC requires additional data collecting. So I agree - let's use winbindd API to get what we can and provide some interface to inquire it via GSSAPI.

I see that winbind_srv_auth() already makes request and gets wbcAuthUserInfo data structure with list of SIDs - this is actually what we need to receive. So we don't even need additional requests for that...
I have reused the concept of handling session key in this flow and added list of ntlm_raw_sid into gss context. Also I think that gss_inquire_sec_context_by_oid can be used to request custom buffer from gssntlmssp (added private OID to header).

I tried to push my new branch but probably I miss write permissions (Error: Permission to gssapi/gss-ntlmssp.git denied to kvv81). So please see my patch (for master) here:
get_sids.patch.gz

Items that can be improved:

• We can take into account that each SID is variable-size structure and store only used bytes (8+4*sub_authority_count), not all 68. This will reduce memory consumption.
• We can allocate sids buffer in gsstlm context dynamically, not statically with pre-defined maximum size (additional code for cleanup will be needed)

[simo5]

Please clone the repository, push in your clone, and then open a PR from there.
I definitely do not want to add fixed size structures, but I really need to see what you propose first.

[kvv81]

Fixed by PR #36