mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-01-15 19:01:55 -06:00
0317255b53
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 <abokovoy@redhat.com> Reviewed-By: Isaac Boukris <iboukris@redhat.com> Reviewed-By: Florence Blanc-Renaud <flo@redhat.com> |
||
|---|---|---|
| .. | ||
| tests | ||
| ipa_kdb_audit_as.c | ||
| ipa_kdb_certauth.c | ||
| ipa_kdb_common.c | ||
| ipa_kdb_delegation.c | ||
| ipa_kdb_kdcpolicy.c | ||
| ipa_kdb_mkey.c | ||
| ipa_kdb_mspac_private.h | ||
| ipa_kdb_mspac.c | ||
| ipa_kdb_passwords.c | ||
| ipa_kdb_principals.c | ||
| ipa_kdb_pwdpolicy.c | ||
| ipa_kdb.c | ||
| ipa_kdb.exports | ||
| ipa_kdb.h | ||
| Makefile.am | ||
| README | ||
| README.s4u2proxy.txt | ||
This is the ipa krb5kdc database backend. As the KDB interfaces heavily with krb5, we inherit its code style as well. However, note the following changes: - no modelines (and different file preamble) - return types don't require their own line - single-statement blocks may optionally be braced - /* and */ do not ever get their own line - C99 for-loops are permitted (and encouraged) - a restricted set of other C99 features are permitted In particular, variable-length arrays, flexible array members, compound literals, universal character names, and //-style comments are not permitted. Use of regular malloc/free is preferred over talloc for new code. By and large, existing code mostly conforms to these requirements. New code must conform to them.