Support server referrals #18
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
abbra
force-pushed
the
support-server-referrals
branch
from
91d10e5 to
ec50b00
Compare
|
@abbra I disable prci service in permanent-ad-ftrivino-2 just in case you want to continue debugging. I need to use the other runners to work with NR stabilization. |
abbra
force-pushed
the
support-server-referrals
branch
11 times, most recently
from
73ab324 to
19a9a1a
Compare
abbra
force-pushed
the
support-server-referrals
branch
7 times, most recently
from
400f68f to
4a1f580
Compare
UPN_DNS_INFO structure contains the client's user principal name (UPN) and a fully qualified domain name. It is used to provide the UPN and the FQDN that corresponds to the client of the ticket. The structure is defined in MS-PAC section 2.10. MS-KILE specification says in the section 3.3.5.6.4.5 that KDCs should return this buffer. It further clarifies in section 3.3.5.2 that if the user account object has no userPrincipalName attribute, UPN_DNS_INFO should be constructed by concatenating user name, the "@" symbol, and the DNS name of the domain. IPA users don't really have userPrincipalName attribute. Instead, we always construct their account names in LOGON Info3 structure by unparsing the canonical principal name without realm, meaning that user principal can be recovered by concatenating the account name and the realm (domain). Unless the account name and unparsed client principal name are different or the primary Info3 gid (group RID) is the one for machine accounts, mark the UPN as constructed. Related: https://pagure.io/freeipa/issue/8319 Signed-off-by: Alexander Bokovoy <[email protected]>
abbra
force-pushed
the
support-server-referrals
branch
3 times, most recently
from
562e1ce to
621edc9
Compare
Helper utility to investigate PAC content of users in trusted environments. Supports direct ticket acquisition and S4U2Self protocol transition. 1. Direct ticket acquisition In direct ticket acquisition mode the utility first does one of the following actions: - obtain a TGT ticket for a user principal using supplied password - import existing TGT from a default credentials cache Once a user TGT is available, the utility will attempt to acquire a service ticket to a service which key is specified in a keytab (default or passed with --keytab option) and simulate establishing context to the service application. If establishing context succeeds, MS-PAC content of the service ticket will be printed out. 2. S4U2Self protocol transition In protocol transition case a service application obtains own TGT using a key from the keytab and then requests a service ticket to itself in the name of the user principal, performing S4U2Self request. If accepting this service ticket succeeds, MS-PAC content of the service ticket will be printed out. If KDC does not support or rejects issuing MS-PAC record for a user, an error message 'KDC has no support for padata type' will be printed. Related: https://pagure.io/freeipa/issue/8319 Signed-off-by: Alexander Bokovoy <[email protected]> Signed-off-by: Isaac Boukris <[email protected]>
When ipa-adtrust-install is used, IPA KDC will be configured to issue tickets with MS-PAC record in them for users and services that have ipaNTSecurityIdentifier (SID) attribute in the LDAP record. Test that a newly added user can kinit and obtain a ticket that has a PAC structure. Test that a service can impersonate a user and the resulting S4U2Self requested service ticket also has PAC structure. Related: https://pagure.io/freeipa/issue/8319 Signed-off-by: Alexander Bokovoy <[email protected]>
Implement minimal server referrals support for enterprise principals as defined in RFC 6806. Use krb5_pac_verify_ext() and krb5_pac_sign_ext() to support cross-realm S4U extensions. We have to verify/sign PAC and take the realm into account for S4U in these cases. The use of extended functions require krb5 1.17+. For PAC verification, we have to filter existing PAC CLIENT-INFO structure in cross-realm S4U case because otherwise old CLIENT-INFO would change the PAC principal due to adding or ommiting the realm in transition. Since a new PAC CLIENT-INFO will be provided by k5_insert_client_info() anyway, we can filter it in all cases. Generate PAC only for the first S4U2Self request to the client realm (client != NULL). Otherwise, use the PAC from the cross-realm ticket. The latter PAC belongs to the impersonated user. Foreign (inner) principal look up in non-AS request returns KRB5_KDB_NOENTRY. Finally, in PAC signing we have to take the realm into account as well for S4U2Self cross-realm operation. This does not work when compiling against krb5 1.17 at the moment because sign_authdata() callback does not know whether we are dealing with an issuing referral or not. In 1.18 a KDC will set a special client flag to signify this when asking KDB driver to sign a PAC record. Fixes: https://pagure.io/freeipa/issue/8319 Signed-off-by: Alexander Bokovoy <[email protected]> Signed-off-by: Isaac Boukris <[email protected]>
Depending on whether identity of a principal was asserted by the KDC or by a service doing protocol transition (S4U2Self), AD DCs add a special extra SID to a PAC record: - S-1-18-1 is a SID for an Authentication Authority Asserted Identity - S-1-18-2 is a SID for a Service Asserted Identity This behavior is governed by [MS-SFU] 3.2.5.1.2 "KDC replies with Service Ticket". In order to add an asserted identity SID, we need to pass down the client flags as set by the KDC and check for a protocol transition bit. Fixes: https://pagure.io/freeipa/issue/8319 Signed-off-by: Alexander Bokovoy <[email protected]>
Previously, FreeIPA only allowed to issue PAC record in a ticket for the following principal types: - for IPA users - for a host principal of one of IPA masters - for a cifs/ or HTTP/ service on one of IPA masters To allow S4U2Self operations over trust to AD, an impersonating service must have PAC record in its TGT to be able to ask AD DCs for a S4U2Self ticket. It means any IPA service performing S4U2Self would need to have PAC record and the constraints above prevent it from doing so. However, depending on whether the service or host principal belongs to one of IPA masters, we need to set proper primary RID to 516 (domain controllers) or 515 (domain computers). Fixes: https://pagure.io/freeipa/issue/8319 Signed-off-by: Alexander Bokovoy <[email protected]>
Somehow, we weren't adding primary group of the user to the list of groups in the PAC Logon Info structure. Related: https://pagure.io/freeipa/issue/8319 Signed-off-by: Alexander Bokovoy <[email protected]>
For Kerberos principal lookup we always need to check whether principal is from our realm. Keep the reference to our realm TGS handy to avoid memory allocations on every lookup. Related: https://pagure.io/freeipa/issue/8319 Signed-off-by: Alexander Bokovoy <[email protected]>
abbra
force-pushed
the
support-server-referrals
branch
2 times, most recently
from
fcda87a to
8a560ce
Compare
Restructure logic of ipadb_get_principal() to separate retrieval of a principal by a name and by an alias. Separate enterprise principal name type processing into a helper function to be able to reuse it for own aliases. Unify code in client referrals part to do the same and use krb5 API to deal with principals rather than parsing strings. The end result is the same but we follow common rules in MIT Kerberos to process principals. An enterprise principal is typically "name@SOMEREALM@REALM", but any principal might be parsed as enterprise principal, so we could get "name@REALM" marked as such. When unparsing the enterprise principal, re-parse it again with default realm values, to get our realm normalization. This behavior would fix situations when GSSAPI calls are operating on a non-qualified principal name that was imported as a GSS_KRB5_NT_ENTERPRISE_NAME when calling gss_import_name(). Related: https://pagure.io/freeipa/issue/8319 Signed-off-by: Alexander Bokovoy <[email protected]> Signed-off-by: Isaac Boukris <[email protected]>
Kerberos service might request a ticket to itself on behalf of a user to perform protocol transition, so-called S4U2Self extension defined in [MS-SFU] specification. Processing of this request by KDC differs for in-realm and cross-realm configurations. Use SMB service to test S4U2Self performed against AD and IPA users. Fixes: https://pagure.io/freeipa/issue/8319 Signed-off-by: Alexander Bokovoy <[email protected]>
389-ds memory autotuning doesn't really work well in containerized environment as it only looks into host-wide /proc/meminfo. It gets fooled by 'missing' memory while there is still enough swap space. This is in particular affects test_commands test suite where ipa-adtrust-install cannot fully proceed and fails. We plan to rebalance test containers' memory split but right now just disable test_commands in Azure CI. Signed-off-by: Alexander Bokovoy <[email protected]>
abbra
force-pushed
the
support-server-referrals
branch
from
8a560ce to
17efe49
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.