Re: ssh key issues
by Andrew Meyer
I tried this. I ran into this problem earlier this year but can't remember what I did to fix it.
3 years, 6 months
Re: Problem with smartcard login when otp is enabled
by Radek Kujawa
Hi.
I am able to reproduce this problem on Fedora 32 (sssd-2.2.3-20), however I
am not able to reproduce this on CentOS 8 (sssd-2.3.1-2). This suggests the
problem was introduced somewhere between sssd 2.2.3 and 2.3.1.
Config on both systems is the same - machines added to IPA domain, user
account has both cert configured for PKINIT and OTP.
Attempting to log in on CentOS 8 displays prompt for Smart Card PIN,
attempting to log in on Fedora 32 displays prompt for OTP factors.
I've tried to analyze the problem and it seems that sss_krb5_prompter
always tries otp on Fedora, even though p11_child finishes successfully and
returns the correct user certificate.
On CentOS 8:
(Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [get_and_save_tgt]
(0x4000): Found Smartcard credentials, trying pkinit.
(...)
(Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]]
[sss_child_krb5_trace_cb] (0x4000): [2185] 1599679459.143791: Upgrading to
FAST due to presence of PA_FX_FAST in reply
(...)
(Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]]
[sss_child_krb5_trace_cb] (0x4000): [2185] 1599679459.143815: Processing
preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-P
K-AS-REQ_OLD (14), PA-FX-FAST (136), PA-PKINIT-KX (147), PA-OTP-CHALLENGE
(141), PA-FX-COOKIE (133), PA-FX-ERROR (137)
(Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]]
[sss_child_krb5_trace_cb] (0x4000): [2185] 1599679459.143816: Received
cookie: MIT
(Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_krb5_responder]
(0x4000): Got question [pkinit].
(Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [answer_pkinit]
(0x4000): [0] Identity
[PKCS11:module_name=/usr/lib64/pkcs11/opensc-pkcs11.so:slotid=0:token=rkujawa]
flags [0].
(Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [answer_pkinit]
(0x4000): Setting pkinit_prompting.
(Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]]
[sss_child_krb5_trace_cb] (0x4000): [2185] 1599679459.143817: Preauth
module pkinit (147) (info) returned: 0/Success
(Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_krb5_prompter]
(0x4000): sss_krb5_prompter name [(null)] banner [(null)] num_prompts [1]
EINVAL.
(Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_krb5_prompter]
(0x4000): Prompt [0][rkujawa PIN].
(Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_krb5_prompter]
(0x0020): Cannot handle password prompts.
On Fedora 32:
(2020-09-09 21:18:16): [krb5_child[1823]] [get_and_save_tgt] (0x4000):
Found Smartcard credentials, trying pkinit.
(...)
(2020-09-09 21:18:16): [krb5_child[1823]] [sss_child_krb5_trace_cb]
(0x4000): [1823] 1599679096.050398: Upgrading to FAST due to presence of
PA_FX_FAST in reply
(...)
(2020-09-09 21:18:16): [krb5_child[1823]] [sss_child_krb5_trace_cb]
(0x4000): [1823] 1599679096.050422: Processing preauth types: PA-PK-AS-REQ
(16), PA-PK-AS-REP_OLD (15), PA-PK-AS-REQ_OLD (14), PA-FX-FAST (136),
PA-PKINIT-KX (147), PA-OTP-CHALLENGE (141), PA-FX-COOKIE (133), PA-FX-ERROR
(137)
(2020-09-09 21:18:16): [krb5_child[1823]] [sss_child_krb5_trace_cb]
(0x4000): [1823] 1599679096.050423: Received cookie: MIT
(2020-09-09 21:18:16): [krb5_child[1823]] [sss_krb5_responder] (0x4000):
Got question [otp].
(2020-09-09 21:18:16): [krb5_child[1823]] [answer_otp] (0x4000): [0] Vendor
[(null)].
(2020-09-09 21:18:16): [krb5_child[1823]] [answer_otp] (0x4000): [0]
Token-ID [(null)].
(2020-09-09 21:18:16): [krb5_child[1823]] [answer_otp] (0x4000): [0]
Challenge [(null)].
(2020-09-09 21:18:16): [krb5_child[1823]] [answer_otp] (0x4000): [0] Flags
[1].
(2020-09-09 21:18:16): [krb5_child[1823]] [answer_otp] (0x2000): Exit
answer_otp during pre-auth.
(2020-09-09 21:18:16): [krb5_child[1823]] [get_and_save_tgt] (0x0400):
krb5_get_init_creds_password returned [11] during pre-auth.
(2020-09-09 21:18:16): [krb5_child[1823]] [k5c_send_data] (0x0200):
Received error code 0
(2020-09-09 21:18:16): [krb5_child[1823]] [pack_response_packet] (0x2000):
response packet size: [15]
(2020-09-09 21:18:16): [krb5_child[1823]] [k5c_send_data] (0x4000):
Response sent.
(2020-09-09 21:18:16): [krb5_child[1823]] [main] (0x0400): krb5_child
completed successfully
This results in PIN never being asked on Fedora.
Unfortunately at this moment I am not able to deliver full logs. Hopefully
Jan will send full logs from his setup ;).
Best regards,
Radoslaw
3 years, 6 months
Can't reinstate replica from scratch after it was off for 6 months
by Konstantin M. Khankin
Hi!
I run IPA on CentOS 7. I have two servers (Leader and Replica, though they
changed roles couple times because of reinstalls), had ca and domain
services on both of them, replication set up and working. I had to switch
off Replica for 6 months. When I turned it on recently, I found expired
certificates, couldn't fix them easily and lost the old Replica - at least
I concluded it was easier to reinstate the Replica than to detangle the
mess I made while was trying to back out of outdated certs. I hit the same
error as I do now though - Invalid Credentials (49).
So I did the following:
1) on Replica - ipa-server-install --uninstall.
2) on Leader - ipa-replica-manage del --force --clean Replica.
3) removed obsolete replication agreement meToReplica from Leader.
4) removed all traces of Replica from DNS.
Then I started to install Replica from scratch:
1) ipa-client-install
2) ipa-replica-install --setup-ca --setup-dns --forwarder X --forwarder Y
Installation consistently fails with:
'''
Run connection check to master
Connection check OK
Configuring directory server (dirsrv). Estimated time: 30 seconds
<...>
[29/42]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 16 seconds elapsed
[ldap://Leader:389] reports: Update failed! Status: [Error (49) - LDAP
error: Invalid credentials]
[error] RuntimeError: Failed to start replication
'''
Logs from Leader, /var/log/dirsrv/slapd-DOMAIN/errors:
'''
[<DATE>] - ERR - NSMMReplicationPlugin - bind_and_check_pwp -
agmt="cn=meToReplica.domain" (Replica:389) - Replication bind with GSSAPI
auth failed: LDAP error 49 (Invalid credentials) ()
"""
I verified clocks on both Replica and Leader - they show the same time
(within 1-2 seconds diff window). In fact, at some point I had Replica
taking time straight from Leader, before they were set up to use the other
common source. I dumped traffic between Leader and Replica - indeed, Leader
tried to authenticate on Replica and Replica replies "Invalid credentials".
I googled this error and read multiple email threads but nothing helped so
far. Replica works fine as IPA client but can't get promoted to a replica.
What am I missing?
Thanks!
--
Khankin Konstantin
3 years, 6 months
FreeIPA 2-way trust with MS AD
by Yuri Krysko
Hello,
I know if the past (late 2018) there was a question about not enough clarity as to what is actually a 2-way trust between FreeIPA and MS AD. Technically, there does not seem to be any difference between 1-way and 2-way trusts. Question: is there a more concrete timeline when you guys plan to implement capability for IdM users to login to MS resources?
Thanks,
Yuri
3 years, 6 months
Running external cert management on Ipa server?
by Dominik Vogt
Hi folks,
a customer wants to use the Redhat certificate system instead of
the one built into freeipa. AFAIK both use dogtag under the hood.
The customer wants to run the certificate system on the same
machine as the ipa server, if possible (because otherwise he needs
more hardware). Redhat support had some unspecific concerns that
RHCS might conflict with the one that is part of freeipa.
Is it possible at all? Will it cause trouble? Has anybody some
experience with that setup?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
3 years, 6 months
RHEL 7 IdM trust to AWS Managed MS AD
by Yuri Krysko
Hello,
Is it possible to create a 2-way trust from RHEL 7 IdM to AWS Managed MS AD? So far, I have not had success creating such trust. My RHEL 7 IdM has FIPS enabled and FIPS set to enforcing.
Ipa-server-4.6.6-11
Thanks much,
Yuri
3 years, 6 months
Delay in behavior when making changes to custom plugins
by Scott Serr
My environment is: CentOS 8.2, FreeIPA 4.8.4, single instance, no clients
My minimal test case plugin looks like this:
user.takes_params += (
Str('useraffiliation?',
cli_name = 'useraffiliation',
label = _('User Affiliation'),
),
)
user.default_attributes.append('useraffiliation')
Say I modify the label. That change isn't shown in IPA cli:
ipa user-find foo --all
Then about an hour later (go eat dinner) then the label has changed.
Restarting the ipa service, another kinit, even rebooting doesn't hurry this process along.
2 Questions:
1. What is causing this delay in reflecting my changes?
2. Is there a way to force my changes to be reflected right away?
Thank you!
3 years, 6 months
Re: Problem with smartcard login when otp is enabled
by Sumit Bose
On Wed, Sep 09, 2020 at 01:56:23PM +0000, Jan Ufnalski via FreeIPA-users wrote:
>
>Configuration: OS:Kubuntu 20.04 LTS, Yubikey 5 with PIV, sssd version: 2.2.3-3, testing in terminal session without graphic interface to exclude problems from graphic interface
>In case when OTP is disabled and yubikey inserted, in login process I get correct prompt for smartcard pin.
>But when OTP is configured in IPA and yubikey inserted, instead getting prompt for smart card pin I get prompt for first factor and second factor.
>In /etc/sssd/sssd.conf [pam] section I have enabled pam_cert_auth. I attatch 2 logs from sssd, one with enabled and one with disabled otp.
>When I configured second computer the same way few weeks ago, everything works okey, but now I have to disable otp to make smartcard work correctly
Hi,
please add 'debug_level = 9' to the [domain/...] section of sssd.conf,
restart SSSD and run the tests again. The please send the domain log and
krb5_child.log.
bye,
Sumit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>#
># /etc/pam.d/common-auth - authentication settings common to all services
>#
># This file is included from other service-specific PAM config files,
># and should contain a list of the authentication modules that define
># the central authentication scheme for use on the system
># (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
># traditional Unix authentication mechanisms.
>#
># As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
># To take advantage of this, it is recommended that you configure any
># local modules either before or after the default block, and use
># pam-auth-update to manage selection of other modules. See
># pam-auth-update(8) for details.
># here are the per-package modules (the "Primary" block)
>auth [default=1 success=ok] pam_localuser.so
>auth [success=2 default=ignore] pam_unix.so nullok_secure
>#auth [success=1 default=ignore] pam_sss.so use_first_pass
>auth sufficient pam_sss.so forward_pass prompt_always # here's the fallback if no module succeeds
>auth requisite pam_deny.so
># prime the stack with a positive return value if there isn't one already;
># this avoids us returning an error just because nothing sets a success code
># since the modules above will each just jump around
>auth required pam_permit.so
># and here are more per-package modules (the "Additional" block)
>auth optional pam_cap.so
># end of pam-auth-update config
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>
>Jan Ufnalski
3 years, 6 months
Re: Renewing a failed to auto-renewal certificate
by Stuart McRobert
Dear flo,
Thanks for the update.
> The IPA services are probably stopped. Can you try
> # ipactl start --ignore-service-failures
That has I believe worked as desired and I can now kinit on the first server.
Cut and paste
# ipactl start --ignore-service-failures
Existing service file detected!
Assuming stale, cleaning and proceeding
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting ipa_memcached Service
Starting httpd Service
Failed to start httpd Service
Forced start, ignoring httpd Service, continuing normal operation
Starting ipa-custodia Service
Starting ntpd Service
Starting pki-tomcatd Service
^Z
[1]+ Stopped ipactl start --ignore-service-failures
[root@freeipa01 sm]# bg
[1]+ ipactl start --ignore-service-failures &
[root@freeipa01 sm]# kinit sm
Password for sm@OUR_DOMAIN
[root@freeipa01 sm]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: sm@OUR_DOMAIN
Valid starting Expires Service principal
09/09/20 14:29:14 10/09/20 14:29:08 krbtgt/OUR_DOMAIN@OUR_DOMAIN
Meanwhile in the background comes
Failed to start pki-tomcatd Service
Forced start, ignoring pki-tomcatd Service, continuing normal operation
Starting ipa-otpd Service
ipa: INFO: The ipactl command was successful
[1]+ Done ipactl start --ignore-service-failures
> # ldapsearch -H ldap://`hostname` -LLL -o ldif-wrap=no -D 'cn=Directory Manager' -W '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn
>
> This should return an entry dn which contains the name of the renewal
> master, for instance:
> dn: cn=CA,cn=hostname.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
That does indeed return our first server 01 as I hoped.
dn: cn=CA,cn=freeipa01... etc
>
> Warning, if the replication got broken, the result may be different on
> other servers. Make sure all the nodes have the same view of who is CA
> renewal master.
I have checked on the other two production freeipa servers and all point
to the first.
> Once you identify the CA renewal master, the repair procedure needs to
> be applied on this node first.
Okay, so I think I need to book a repair slot as I assume our authentication
will fail during the time travel.
Thanks
Best wishes
Stuart
3 years, 6 months
Problem with smartcard login when otp is enabled
by Jan Ufnalski
Configuration: OS:Kubuntu 20.04 LTS, Yubikey 5 with PIV, sssd version: 2.2.3-3, testing in terminal session without graphic interface to exclude problems from graphic interface
In case when OTP is disabled and yubikey inserted, in login process I get correct prompt for smartcard pin.
But when OTP is configured in IPA and yubikey inserted, instead getting prompt for smart card pin I get prompt for first factor and second factor.
In /etc/sssd/sssd.conf [pam] section I have enabled pam_cert_auth. I attatch 2 logs from sssd, one with enabled and one with disabled otp.
When I configured second computer the same way few weeks ago, everything works okey, but now I have to disable otp to make smartcard work correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
auth [default=1 success=ok] pam_localuser.so
auth [success=2 default=ignore] pam_unix.so nullok_secure
#auth [success=1 default=ignore] pam_sss.so use_first_pass
auth sufficient pam_sss.so forward_pass prompt_always # here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_cap.so
# end of pam-auth-update config
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Jan Ufnalski
3 years, 6 months