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>
"Kerberos principal expiration" is set in UTC and when server is in
different timezone, the time difference between timezone is respected by
the IPA server/client for Kerberos authentication.
The problem is due to mktime() assuming default time zone but since we
parse the time using Zulu (UTC+0) timezone, mktime() forces current time
zone offset added.
The method is using mktime() and comparing to the current time obtained
with time(NULL). According to its man page, mktime is considering the
time as local time:
The mktime() function converts a broken-down time structure, expressed
as local time, to calendar time representation.
Instead mktime() we should use timegm(). The problem is that it is
non-standard GNU extension and it is recommended (in the man page for
timegm(3)) to avoid its use. An alternative is to set TZ=UTC, call
mktime(), unset TZ, but since we are running in a multi-threaded
environment this is problematic.
On the other hand, we already rely on GNU extensions and enable them
with -D_DEFAULT_SOURCE=1, so use of timegm() is enabled already.
The fix, therefore, is to use timegm() instead of mktime() in
daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c in two places where we
first do 'strptime()' with Zulu time zone (in ipapwd_pre_bind() and
ipapwd_write_krb_keys()).
Fixes: https://pagure.io/freeipa/issue/8362
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
Reviewed-By: Christian Heimes <cheimes@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>
Require OpenDNSSEC 2.1.6-5 with fix for RHBZ#1825812 (DAC override AVC)
Allow ipa-dnskeysyncd to connect to enforcer.sock (ipa_dnskey_t write
opendnssec_var_run_t and connectto opendnssec_t). The
opendnssec_stream_connect interface is available since 2016.
Change the owner of the ipa-ods-exporter socket to ODS_USER:ODS_GROUP.
The ipa-ods-exporter service already runs as ODS_USER.
Fixes: https://pagure.io/freeipa/issue/8283
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@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>
While other password policies were properly ignored the password
history was always being saved if the global history size was
non-zero.
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Password changes performed by cn=Directory Manager are excluded from
password policy checks according to [1]. This is correctly handled by
ipa-pwd-extop in case of a normal Kerberos principal in IPA. However,
non-kerberos accounts were not excluded from the check.
As result, password updates for PKI CA admin account in o=ipaca were
failing if a password policy does not allow a password reuse. We are
re-setting the password for PKI CA admin in ipa-replica-prepare in case
the original directory manager's password was updated since creation of
`cacert.p12`.
Do password policy check for non-Kerberos accounts only if it was set by
a regular user or admin. Changes performed by a cn=Directory Manager and
passsync managers should be excluded from the policy check.
Fixes: https://pagure.io/freeipa/issue/7181
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
[1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/user_account_management-managing_the_password_policy
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
SLAPI_BIND_TARGET_DN is deprecated since 2011 by 389-ds team,
see commit f6397113666f06848412bb12f754f04258cfa5fa in 389-ds:
https://pagure.io/389-ds-base/c/f6397113666f06848412bb12f754f04258cfa5fa?branch=master
Use SLAPI_BIND_TARGET_SDN instead and move internal ipa-pwd-extop
helpers to accept Slapi_DN references rather than strings.
Related: https://pagure.io/freeipa/issue/7181
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
The communication between ods-signer and the socket-activated process
has changed with OpenDNSSEC 2.1. Adapt ipa-ods-exporter to support also
the new protocol.
The internal database was also modified. Add a wrapper calling the
right code (table names hab=ve changed, as well as table columns).
With OpenDNSSEC the policy also needs to be explicitely loaded after
ods-enforcer-db-setup has been run, with
ods-enforcer policy import
The command ods-ksmutil notify must be replace with ods-enforce flush.
Related: https://pagure.io/freeipa/issue/8214
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@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>
Samba did remove unixid_from_*() helpers in the upstream commit
c906153cc7af21abe508ddd30c447642327d6a5d (Samba 4.11). Since they are
very simple, make a local copy instead.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1757089
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@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>
Old implementation handles username and group names with
one common call. Character @ is used in the call to detect UPN.
Group name can legaly contain this character and therefore the
common approach doesn't work in such case.
Also the original call is less efficient because it tries to resolv
username allways then it fallback to group resolution.
Here we implement two new separate calls for resolving users and
groups.
Fixes: https://bugzilla.redhat.com/1746951
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>
Simulate getgrgid_r() timeout when packing list of groups user is a
member of in pack_ber_user().
Related: https://pagure.io/freeipa/issue/8044
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
A return code LDAP_NO_SUCH_OBJECT will tell SSSD on the IPA client to
remove the searched object from the cache. As a consequence
LDAP_NO_SUCH_OBJECT should only be returned if the object really does
not exists otherwise the data of existing objects might be removed form
the cache of the clients causing unexpected behaviour like
authentication errors.
Currently some code-paths use LDAP_NO_SUCH_OBJECT as default error code.
With this patch LDAP_NO_SUCH_OBJECT is only returned if the related
lookup functions return ENOENT. Timeout related error code will lead to
LDAP_TIMELIMIT_EXCEEDED and LDAP_OPERATIONS_ERROR is used as default
error code.
Fixes: https://pagure.io/freeipa/issue/8044
Reviewed-By: Alexander Bokovoy <abokovoy@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>
Domain member is represented for SMB as a machine account with
NetBIOS name ending with '$', e.g. 'FILESERVER$'. Such name will need to
be resolved as a POSIX account by smbd at some point but first we need
to make sure it is returned as a machine account through PASSDB layer.
In addition to that, machine accounts are normal Kerberos services,
named as 'cifs/<hostname>@REALM'. This name also will need to be
resolved as a POSIX account by smbd on the domain controller.
These two factors mean that LDAP entry for SMB kerberos service has to
have multiple 'uid' values. This is allowed by the LDAP schema and we
need to support it in ipasam.
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>
Samba may ask for an account based on a SID value. Implement a callback
to return a result of such lookup since we should have SID for every
domain account that is supposed to be usable through SMB protocol.
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>
Upgrade code had Kerberos principal names mixed up: instead of creating
krbtgt/LOCAL-FLAT@REMOTE and marking LOCAL-FLAT$@REMOTE as an alias to
it, it created LOCAL-FLAT$@REMOTE Kerberos principal and marked
krbtgt/LOCAL-FLAT@REMOTE as an alias.
This differs from what Active Directory expects and what is created by
ipasam plugin when trust is established. When upgrading such deployment,
an upgrade code then unexpectedly failed.
Resolves: https://pagure.io/freeipa/issue/7992
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Replace the @PYTHONSHEBANG@ substitution with a valid #!/usr/bin/python3
shebang. This turns Python .in files into valid Python files. The files
can now be checked with pylint and IDEs recognize the files as Python
files.
The shebang is still replaced with "#!$(PYTHON) -E" to support
platform-python.
Related: https://pagure.io/freeipa/issue/7984
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
In 2012, ldbm backend in 389-ds started checking entry modification
after running betxnpreop plugins by comparing a number of modifications
before and after. If that number didn't change, it is considered that
plugins didn't modify the list.
ipa-pwd-extop actually removed and re-added modification to ipaNTHash if
it contained 'MagicRegen' value. This did not work since commit
https://pagure.io/389-ds-base/c/6c17ec56076d34540929acbcf2f3e65534060a43
but we were lucky nothing in FreeIPA code actually relied on that except
some code paths in ipasam Samba passdb driver. However, Samba didn't
reach the point where the code was triggered -- until now.
With support to run Samba as a domain member in IPA domain, that code
path is triggered for Kerberos service principals of domain members
(cifs/client.example.test, ...) and NT hash extraction from Kerberos
keys does not work.
Fix ipa-pwd-extop to follow recommendations in
https://pagure.io/389-ds-base/issue/387#comment-120145 and
https://pagure.io/389-ds-base/issue/50369#comment-570696
Fixes: https://pagure.io/freeipa/issue/7953
Reviewed-By: Christian Heimes <cheimes@redhat.com>
