Some places have to use the old name because it's part of the stable API
or stable LDAP attributes.
See: https://tools.ietf.org/id/draft-knodel-terminology-01.html
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Use OpenSSL's HMAC API instead of NSS.
Fixes: Fixes: https://pagure.io/freeipa/issue/6857
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Refactoring of the get_principal() code in commit
b5876f30d4 broke handling of enterprise
principal lookup for AS request (kinit -E user@ipa.test@IPA.TEST).
Related: https://pagure.io/freeipa/issue/8319
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
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 <abokovoy@redhat.com>
Signed-off-by: Isaac Boukris <iboukris@redhat.com>
Reviewed-By: Isaac Boukris <iboukris@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
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 <abokovoy@redhat.com>
Reviewed-By: Isaac Boukris <iboukris@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
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 <abokovoy@redhat.com>
Reviewed-By: Isaac Boukris <iboukris@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
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 <abokovoy@redhat.com>
Reviewed-By: Isaac Boukris <iboukris@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
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 <abokovoy@redhat.com>
Reviewed-By: Isaac Boukris <iboukris@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
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 <abokovoy@redhat.com>
Signed-off-by: Isaac Boukris <iboukris@redhat.com>
Reviewed-By: Isaac Boukris <iboukris@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
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 <abokovoy@redhat.com>
Signed-off-by: Isaac Boukris <iboukris@redhat.com>
Reviewed-By: Isaac Boukris <iboukris@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
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>
BER structure representing a string might not have termination '\0'
character, thus we should use length-bound functions to operate on it.
Memory handling of LDAP values was leaving previous vals over iteration.
Also, when freeing vals, we need to explicitly set it to NULL.
Fixes: https://pagure.io/freeipa/issue/8291
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-by: Simo Sorce <ssorce@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Simo Sorce <ssorce@redhat.com>
Related: https://pagure.io/freeipa/issue/8291
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Simo Sorce <ssorce@redhat.com>
Also add runstatedir autoconf var. IPA requires autoconf 2.59. The
variable will be available with autoconf 2.70.
Fixes: https://pagure.io/freeipa/issue/8272
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
NIST SP 800-63-3B sets a recommendation to have password length upper bound limited in A.2:
https://pages.nist.gov/800-63-3/sp800-63b.html#appA
Users should be encouraged to make their passwords as lengthy as they
want, within reason. Since the size of a hashed password is independent
of its length, there is no reason not to permit the use of lengthy
passwords (or pass phrases) if the user wishes. Extremely long passwords
(perhaps megabytes in length) could conceivably require excessive
processing time to hash, so it is reasonable to have some limit.
FreeIPA already applied 256 characters limit for non-random passwords
set through ipa-getkeytab tool. The limit was not, however, enforced in
other places.
MIT Kerberos limits the length of the password to 1024 characters in its
tools. However, these tools (kpasswd and 'cpw' command of kadmin) do not
differentiate between a password larger than 1024 and a password of 1024
characters. As a result, longer passwords are silently cut off.
To prevent silent cut off for user passwords, use limit of 1000
characters.
Thus, this patch enforces common limit of 1000 characters everywhere:
- LDAP-based password changes
- LDAP password change control
- LDAP ADD and MOD operations on clear-text userPassword
- Keytab setting with ipa-getkeytab
- Kerberos password setting and changing
Fixes: https://pagure.io/freeipa/issue/8268
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-by: Simo Sorce <ssorce@redhat.com>
Reviewed-By: Simo Sorce <ssorce@redhat.com>
audit_as_req() callback has changed its signature with MIT krb5 commit
20991d55efbe1f987c1dbc1065f2d58c8f34031b in 2017, we should preserve the
change for any newer DAL versions. Otherwise audit_as_req() callback
would reference wrong data and we might crash.
Fixes: https://pagure.io/freeipa/issue/8200
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
No supported Linux distro packages a version of krb5 with this DAL, so
we don't lose anything by removing it.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Provide stubs for backward compatibility. DAL 8.0 was released with
krb5-1.18, which is part of Fedora 32+.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
In ac8865a22138ab0c657208c41be8fd6bc7968148 (between 1.17 and 1.18),
krb5 removed this flag, and always accepts aliases.
Related-to: https://pagure.io/freeipa/issue/7879
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
`vals` is often leaked during early exit. Refactor function to use a
single exit path to prevent this.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
`client` is not intended to be modified as a parameter of the AS check
function. Fixes an "incompatible pointer type" compiler warning.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
With commit 15ff9c8 a check was removed and as a result Kerberos keys
are unconditionally added to the user entry struct if they are
available. As a result the password related pre-authentication methods
PA-ENC-TIMESTAMP and PA-ETYPE-INFO2 are advertised in the NEEDED_PREAUTH
reply to an AS_REQ.
With respect to the KDC policies this does not matter much because if
password authentication is disabled for the given principal the policy
will reject the AS_REQ if the user tries password authentication. This
is possible because with commit 15ff9c8 kinit will ask for a password if
called without any additional options (e.g. armor ticket or PKINIT
identity). Before 15ff9c8 was committed it just failed with 'kinit:
Pre-authentication failed: Invalid argument while getting initial
credentials' because no suitable pre-authentication method was
available. This is the same behavior as if no password was set for the
given principal.
But with this change SSSD fails to detect the available authentication
types for the given principal properly. As described in
https://docs.pagure.org/SSSD.sssd/design_pages/prompting_for_multiple_authentication_types.html
SSSD uses the MIT Kerberos responder interface to determine the
available authentication methods for the principal and does not check
the ipaUserAuthType LDAP attribute. As a result if a user has 2FA (otp)
authentication configured, which implies that a password is set as the
first factor, the responder interface will always indicate that password
authentication is available even if only opt is enabled for the user.
In this case SSSD will use a prompting which indicates that the second
factor might be optional. Additionally if prompting the user directly is
not possible (e.g. ssh with ChallengeResponseAuthentication /
KbdInteractiveAuthentication disabled) the single string entered by the
user will always be assumed as a password and not as a combination of
password and otp-token value. As a consequence authentication will
always fail because password authentication is disabled for the user and
since SSSD does not do try-and-error 2FA is not tried.
This patch add back the check so that if password authentication is not
available for the principal the Kerberos will not be added to the entry
struct and the KDC will not advertise PA-ENC-TIMESTAMP or
PA-ETYPE-INFO2. If you think this is wrong and the behavior added by
15ff9c8 should be preferred SSSD handing of the available authentication
types must be extended to read ipaUserAuthType as well to restore the
user experience with respect to 2FA prompting and ssh behavior.
Related to https://pagure.io/freeipa/issue/8001
Reviewed-By: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
For the authentication indicators 'otp', 'radius', 'pkinit', and
'hardened', allow specifying maximum ticket life and maximum renewable
age in Kerberos ticket policy.
The policy extensions are now loaded when a Kerberos principal data is
requested by the KDC and evaluated in AS_REQ KDC policy check. If one of
the authentication indicators mentioned above is present in the AS_REQ,
corresponding policy is applied to the ticket.
Related: https://pagure.io/freeipa/issue/8001
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
lcontext may be NULL here, probably due to a restarted 389ds. Based on
a patch by Rob Crittenden.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
We created a Kerberos kdcpolicy plugin to enforce user
pre-authentication policy for newly added pkinit and hardened policy.
In the past version of freeIPA, password enforcement exists but was done
by removing key data for a principal while parsing LDAP entry for it.
This hack is also removed and is now also enforced by kdcpolicy plugin
instead.
Resolves: https://pagure.io/freeipa/issue/8001
Signed-off-by: Changmin Teng <cteng@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Simo Sorce <ssorce@redhat.com>
Reviewed-By: Robbie Harwood <rharwood@redhat.com>
As new authentication indicators implemented, we also modified server
API to support those new values. Also, "krbprincipalauthind" attribute
is modified to use a pre-defined set of values instead of arbitrary
strings.
Resolves: https://pagure.io/freeipa/issue/8001
Signed-off-by: Changmin Teng <cteng@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Simo Sorce <ssorce@redhat.com>
Reviewed-By: Robbie Harwood <rharwood@redhat.com>
ipadb_get_global_config() is permitted to return NULL.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Since krb5_klog_syslog() always needs parameters from syslog.h, move the
include into ipa_krb5.h.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
SMB service on IPA domain member will have both ipaIDOjbect and ipaUser
object classes. Such service will have to be treated as a user in order
to issue MS-PAC record for it.
Fixes: https://pagure.io/freeipa/issue/3999
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Since LDAP operations used by ipa-kdb driver are synchronous, the
timeout specified here is blocking entire KDC. It is worth reducing the
timeout and since AS REQ processing timeout in KDC is 1 minute, reducing
the timeout for LDAP operations down to 30 seconds allows KDC to
respond promptly in worst case scenario as well.
Fixes: https://pagure.io/freeipa/issue/7217
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Robbie Harwood <rharwood@redhat.com>
Fix potential NULL pointer deref in ipadb_mspac_get_trusted_domains().
In theory, dn could be empty and rdn NULL. The man page for ldap_str2dn()
does not guarantee that it returns a non-empty result.
See: https://pagure.io/freeipa/issue/7738
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
On two occasions C code abused strncpy()'s length limitation to copy a
string of known length without the trailing NULL byte. Recent GCC is
raising the compiler warning:
warning: ‘strncpy’ output truncated before terminating nul copying as
many bytes from a string as its length [-Wstringop-truncation]
Use memcpy() instead if strncpy() to copy data of known size.
See: https://pagure.io/freeipa/issue/7738
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The ipadb_free() and ipadb_alloc() functions are only used with
KRB5_KDB_DAL_MAJOR_VERSION 5.
ipa_kdb.c:639:13: warning: ‘ipadb_free’ defined but not used [-Wunused-function]
ipa_kdb.c:634:14: warning: ‘ipadb_alloc’ defined but not used [-Wunused-function]
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Currently there is already code to make sure that after trust is established an
AS-REQ of the local HTTP principal causes a refresh of the internal structures
holding the information about the trusted domains.
But this refreshes only the data of the current krb5kdc worker process on the
local host. Other workers and the KDCs on other hosts will update the data
eventually when a request with a principal from a trusted realm is handled.
During this phase, which might last quite long if remote principals are only
handled rarely, TGTs for local principals might or might not contain a PAC
because the decision if a PAC should be added or not is based on the
information about trusted domains. Since the PAC is needed to access services
on the AD side this access might fail intermittently depending which worker
process on which host is handling the request. This might e.g. affect SSSD
running on the IPA server with two-way trust.
To fix this this patch calls ipadb_reinit_mspac() whenever a PAC is needed but
without the 'force' flag so that the refresh will only happen if it wasn't
called recently (currently not more often than once a minute).
An alternative might be to do the refresh only when processing cross-realm TGT
requests. But this would be already too late because the local principal asking
for a cross-realm ticket would not have a PAC and hence the first attempt will
still fail due to the missing PAC. And injecting the PAC in the cross-realm TGT
while there is none in the requesting ticket does not sound right.
Related to https://pagure.io/freeipa/issue/7351
Reviewed-By: Simo Sorce <ssorce@redhat.com>
The certauth plugin is configured in /etc/krb5.conf independently form
the database module. As a result the IPA certauth plugin can be added to
the configuration without the IPA DAL driver. Since the IPA certauth
plugin depends on the presence of the IPA DAL driver this patch adds a
magic value at the beginning of struct ipadb_context which can be
checked to see if the IPA DAL driver is properly initialized.
Resolves https://pagure.io/freeipa/issue/7261
Reviewed-By: Christian Heimes <cheimes@redhat.com>
When testing KDC code in cmocka we rely on libkrb5 defaults.
libkrb5 would read /etc/krb5.conf by default and would load a KDB
module from there if it is defined for the test realm (EXAMPLE.COM).
Since EXAMPLE.COM is a common name used for test realms, make sure to
not using /etc/krb5.conf from the system. Instead, force KRB5_CONFIG to
/dev/null so that only libkrb5 compiled-in defaults are in use.
In such setup libkrb5 will attempt to load KDB driver db2 for our test
realm. db2 driver doesn't fail if its database is not available (unlike
FreeIPA's one), so it survives initialization.
As result, ipa-kdb-tests pass without unexpected breakage.
Reviewed-By: Christian Heimes <cheimes@redhat.com>
krb5-1.16 includes DAL version 7, which changes the signature of
audit_as_req to include local and remote address parameters.
This patch just enables building against the new DAL version and bumps
the minimum in freeipa.spec.in, but doesn't use the new information
for anything.
Reviewed-By: Tomas Krizek <tkrizek@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
While processing enterprise principals the information about trusted domains
might not be up-to-date. With this patch ipadb_reinit_mspac() is called if an
unknown domain is part of the enterprise principal.
Resolves https://pagure.io/freeipa/issue/7172
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
KDC crashes on quite random interval while trying to reach LDAP
https://pagure.io/freeipa/issue/7017
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Add `includedir /etc/krb5.conf.d` to /etc/krb5.conf only if
/etc/krb5.conf.d exists.
Do not rely on /etc/krb5.conf.d to enable the certauth plugin.
This fixes install on platforms which do not have /etc/krb5.conf.d.
https://pagure.io/freeipa/issue/6589
Reviewed-By: Martin Babinsky <mbabinsk@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Lukas Slebodnik <lslebodn@redhat.com>
Currently the certauth plugin use the unmodified principal from the
request to lookup the user. This might fail if e.g. enterprise
principals are use. With this patch the canonical principal form the kdc
entry is used.
Resolves https://pagure.io/freeipa/issue/6993
Reviewed-By: David Kupka <dkupka@redhat.com>
We automatically add 'otp' and 'radius' authentication indicators when
pre-authentication with OTP or RADIUS did succeed. Do the same for
certauth-based pre-authentication (PKINIT).
A default PKINIT configuration does not add any authentication
indicators unless 'pkinit_indicator = pkinit' is set in kdc.conf.
Unfortunately, modifying kdc.conf automatically is a bit more
complicated than modifying krb5.conf. Given that we have 'otp' and
'radius' authentication indicators also defined in the code not in the
kdc.conf, this change is following an established trend.
SSSD certauth interface does not provide additional information about
which rule(s) succeeded in matching the incoming certificate. Thus,
there is not much information we can automatically provide in the
indicator. It would be good to generate indicators that include some
information from the certmapping rules in future but for now a single
'pkinit' indicator is enough.
Fixes https://pagure.io/freeipa/issue/6736
Reviewed-By: Simo Sorce <ssorce@redhat.com>
With this patch the certificate mapping rules are reloaded every 5
minutes.
Resolves https://pagure.io/freeipa/issue/6963
Reviewed-By: David Kupka <dkupka@redhat.com>
When ADtrust is installed we add a PAC to all tickets, during protocol
transition we need to generate a new PAC for the requested user ticket,
not check the existing PAC on the requestor ticket.
https://pagure.io/freeipa/issue/6862
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
