kinit -n asking for password on clients
by John Ratliff
When trying to do pkinit, if I do kinit -n on one of the IdM servers, it
works fine. If I try on a client machine, it asks me for the password
for WELLKNOWN/ANONYMOUS@REALM.
I have the pkinit_anchors setup for the realm. As I'm trying to do
anonymous pkinit, I think I don't need a client certificate.
On the server, I get this:
$ KRB5_TRACE="/dev/stderr" kinit -n
[13061] 1518402857.924212: Getting initial credentials for
WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM
[13061] 1518402857.929673: Sending request (200 bytes) to IDM.EXAMPLE.COM
[13061] 1518402857.931830: Initiating TCP connection to stream
10.77.9.101:88
[13061] 1518402857.932241: Sending TCP request to stream 10.77.9.101:88
[13061] 1518402857.939162: Received answer (359 bytes) from stream
10.77.9.101:88
[13061] 1518402857.939180: Terminating TCP connection to stream
10.77.9.101:88
[13061] 1518402857.939284: Response was from master KDC
[13061] 1518402857.939380: Received error from KDC:
-1765328359/Additional pre-authentication required
[13061] 1518402857.939474: Processing preauth types: 16, 15, 14, 136,
19, 147, 2, 133
[13061] 1518402857.939499: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[13061] 1518402857.939509: Received cookie: MIT
[13061] 1518402857.939563: Preauth module pkinit (147) (info) returned:
0/Success
[13061] 1518402857.940352: PKINIT client computed kdc-req-body checksum
9/D98A0144E7E4ACC66B63EBCA98379AB9F055D143
[13061] 1518402857.940369: PKINIT client making DH request
[13061] 1518402858.935: Preauth module pkinit (16) (real) returned:
0/Success
[13061] 1518402858.956: Produced preauth for next request: 133, 16
[13061] 1518402858.994: Sending request (1408 bytes) to IDM.EXAMPLE.COM
[13061] 1518402858.1091: Initiating TCP connection to stream 10.77.9.101:88
[13061] 1518402858.1187: Sending TCP request to stream 10.77.9.101:88
[13061] 1518402858.43063: Received answer (2880 bytes) from stream
10.77.9.101:88
[13061] 1518402858.43088: Terminating TCP connection to stream
10.77.9.101:88
[13061] 1518402858.43198: Response was from master KDC
[13061] 1518402858.43258: Processing preauth types: 17, 19, 147
[13061] 1518402858.43273: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[13061] 1518402858.43300: Preauth module pkinit (147) (info) returned:
0/Success
[13061] 1518402858.44150: PKINIT client verified DH reply
[13061] 1518402858.44189: PKINIT client found id-pkinit-san in KDC cert:
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM
[13061] 1518402858.44199: PKINIT client matched KDC principal
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM against id-pkinit-san; no EKU
check required
[13061] 1518402858.62345: PKINIT client used KDF 2B06010502030602 to
compute reply key aes256-cts/00E0
[13061] 1518402858.62395: Preauth module pkinit (17) (real) returned:
0/Success
[13061] 1518402858.62402: Produced preauth for next request: (empty)
[13061] 1518402858.62414: AS key determined by preauth: aes256-cts/00E0
[13061] 1518402858.62547: Decrypted AS reply; session key is:
aes256-cts/96F0
[13061] 1518402858.62589: FAST negotiation: available
[13061] 1518402858.62692: Initializing
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 with default princ
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
[13061] 1518402858.62770: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1
[13061] 1518402858.62846: Storing config in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 for
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM: fast_avail: yes
[13061] 1518402858.62878: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/fast_avail/krbtgt\/IDM.EXAMPLE.COM\@IDM.EXAMPLE.COM(a)X-CACHECONF:
in KEYRING:persistent:760400007:krb_ccache_f3PFEy1
[13061] 1518402858.62933: Storing config in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 for
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM: pa_type: 16
[13061] 1518402858.62954: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/pa_type/krbtgt\/IDM.EXAMPLE.COM\@IDM.EXAMPLE.COM(a)X-CACHECONF:
in KEYRING:persistent:760400007:krb_ccache_f3PFEy1
But on the client, I get this:
$ KRB5_TRACE="/dev/stderr" kinit -n
[2941] 1518402820.155827: Getting initial credentials for
WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM
[2941] 1518402820.156298: Sending request (200 bytes) to IDM.EXAMPLE.COM
[2941] 1518402820.158723: Resolving hostname paine.example.com.
[2941] 1518402820.159975: Resolving hostname phantom.example.com.
[2941] 1518402820.160757: Resolving hostname paine.example.com.
[2941] 1518402820.161411: Initiating TCP connection to stream
204.89.253.101:88
[2941] 1518402820.162065: Sending TCP request to stream 204.89.253.101:88
[2941] 1518402820.168495: Received answer (359 bytes) from stream
204.89.253.101:88
[2941] 1518402820.168532: Terminating TCP connection to stream
204.89.253.101:88
[2941] 1518402820.169917: Response was from master KDC
[2941] 1518402820.169974: Received error from KDC:
-1765328359/Additional pre-authentication required
[2941] 1518402820.170029: Processing preauth types: 16, 15, 14, 136, 19,
147, 2, 133
[2941] 1518402820.170051: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[2941] 1518402820.170062: Received cookie: MIT
Password for WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM:
[2941] 1518402833.34612: Preauth module encrypted_timestamp (2) (real)
returned: -1765328252/Password read interrupted
kinit: Pre-authentication failed: Password read interrupted while
getting initial credentials
Suggestions on what I'm missing?
Thanks.
3 weeks, 5 days
automember hostgroup by account?
by Amos
Is it possible to have an automember rule to add a host to a hostgroup
based on the account used with ipa-install-client?
Amos
1 month, 3 weeks
IPA and legacy systems
by Ronald Wimmer
What would be a good solution to add systems where the FQDN cannot be
changed?
Would it make sense to add a second DNS A Record in the IPA domain for
each of these systems?
Is there any experience on how to deal with such a situation?
Thanks a lot in advance!
Cheers,
Ronald
2 months, 1 week
freeipa with sudo and 2FA (OTP)
by John Ratliff
I'm trying to setup freeipa with OTP. I created a TOTP under my user in
freeipa and updated my user to use 2FA (password + OTP).
When I try to do sudo, it only asks for my password and it fails every
time (presumably because it isn't getting the OTP first).
I didn't see anything useful in the sss_sudo logs, even after adding
debug_level = 6 in the config.
What can I do to further troubleshoot this?
Thanks.
4 months, 2 weeks
Force users to create OTP token on first login
by Russ Long
Is there a way to put a policy or something in place, so when users login for the first time, they are forced to create an OTP Token? We need to force OTP into the system as well as the servers that authenticate with it.
Thanks!
10 months
Re: CA Master Confusion
by Florence Blanc-Renaud
On 8/6/19 9:21 PM, Auerbach, Steven via FreeIPA-users wrote:
> As I work through understanding the current state of my CA mastering in this realm I am getting results I do not understand from these ipa commands (on the v4.6.4 server) and from the ldapsearch commands (on the v3.0.0 server):
> On the v4.6.4 replica (ipa<3>):
> $ sudo ipa config-show |grep 'CA renewal master'
> [sudo] password for <user>:
> $
> $
>
> On the v3.0.0 (ipa<1>):
> $ sudo ldapsearch -H ldap://$HOSTNAME -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=fbog,dc=local' '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn
> [sudo] password for <user>:
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base <cn=masters,cn=ipa,cn=etc,dc=<mydomain>,dc=local> with scope subtree
> # filter: (&(cn=CA)(ipaConfigString=caRenewalMaster))
> # requesting: dn
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
Hi,
the ipaConfigString=caRenewalMaster attribute was introduced in freeIPA
4.0 (please see [1] Howto/Promote_CA_to_Renewal_and_CRL_Master), hence I
am not surprised that the search does not return anything.
When the 3.0 server was installed, the attribute did not exist yet. When
the 4.x replica was installed, the attribute was not added since the new
replica wasn't CA master.
As the attribute is not set at all, the ipa config-show command
(internally using the same ldapsearch you did) is unable to find a CA
master.
If you want to move the CA master role to ipa3, just follow the steps in
[1], making sure to apply the steps for the corresponding IPA version.
Also please note that we do not recommend using versions 3.x and 4.x
together over a long period of time. This is completely OK when you want
to migrate but once you have ensured all the services are properly
working, the 3.x master should be decommissioned. Please see [2].
HTH,
flo
[1] https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master
[2]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
>
>
> Neither tells me anything. Is it possible that the original installation never had a CA master at all? This seems odd considering when I look for CA Master(s), on the v4.6.4 (ipa<3>) tells me:
>
> $ sudo ipa server-role-find --role 'CA server'
> [sudo] password for <user>:
> ----------------------
> 3 server roles matched
> ----------------------
> Server name: ipa<2>.mydomain.local
> Role name: CA server
> Role status: absent
>
> Server name: ipa<1>.mydomain.local
> Role name: CA server
> Role status: enabled
>
> Server name: ipa<3>.mydomain.local
> Role name: CA server
> Role status: absent
> ----------------------------
> Number of entries returned 3
> ----------------------------
>
> And on the v3.0.0 (ipa<1>) I get:
>
> $ sudo ldapsearch -H ldap://$HOSTNAME -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=<mydomain>,dc=local' '(&(cn=CA)(ipaConfigString=caServer))' dn
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base <cn=masters,cn=ipa,cn=etc,dc=fbog,dc=local> with scope subtree
> # filter: (&(cn=CA)(ipaConfigString=caServer))
> # requesting: dn
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
> I know I am missing something basic and fundamental here. Is there a CA Master or not? If not, would I want to just enable the CA Master on the newest server (ipa<3>)?
>
> The way forward is not clear.
> -Steven Auerbach
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
10 months, 1 week
ipa vault: internal error, "Invalid Credential"
by Dmitry Perets
Hi,
Pretty much any vault-related calls in one of my environments result in the internal error, although the call seems to (partially) succeed.
For example:
# ipa vault-add test --type standard
ipa: ERROR: an internal error has occurred
But the vault is created:
# ipa vault-find
---------------
1 vault matched
---------------
Vault name: test
Type: standard
Vault user: admin
----------------------------
Number of entries returned 1
----------------------------
I'll get the same erorr if I try "ipa vault-del", "vault-archive" or "vault-retrieve".
At the same time, the following is written in /var/log/messages:
Sep 19 23:54:39 t-idm-ber800-1 server: Invalid Credential.
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cmscore.authentication.CertUserDBAuthentication.authenticate(CertUserDBAuthentication.java:174)
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.realm.PKIRealm.authenticate(PKIRealm.java:112)
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.ProxyRealm.authenticate(ProxyRealm.java:85)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.authenticator.SSLAuthenticator.authenticate(SSLAuthenticator.java:114)
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.doSubAuthenticate(SSLAuthenticatorWithFallback.java:47)
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate(AbstractPKIAuthenticator.java:89)
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.authenticate(SSLAuthenticatorWithFallback.java:59)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:578)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
Sep 19 23:54:39 t-idm-ber800-1 server: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
Sep 19 23:54:39 t-idm-ber800-1 server: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
Sep 19 23:54:39 t-idm-ber800-1 server: at java.lang.Thread.run(Thread.java:748)
Any idea what could go wrong here....?
Thanks.
Info: ipa-server 4.6.4 on RHEL 7.6, and I am running these commands from the IPA server itself, on which CA and KRA are installed (in fact, it's the only active CA/KRA master in that environment).
---
Regards,
Dmitry Perets
10 months, 1 week
Re: Enabling more FreeIPA CA servers
by Fraser Tweedale
Hi Stuart,
Adding the freeipa-users@ mailing list for visibility.
I'd have to work through your scenario to work out why it fails.
But it may be some time before I get around to that.
I think your idea to first try creating a CA replica on F28 before
moving forward to F30 is a sensible thing to try.
One question though: are you on Domain Level 0 or 1?
(`ipa domainlevel-get`).
Cheers,
Fraser
On Thu, Sep 26, 2019 at 07:35:58PM +0100, Stuart McRobert wrote:
> Dear Fraser,
>
> I've read through lots of posts but I am uncertain about the best way
> forward and wonder if I could seek your guidance? I just don't want to break
> things.
>
> Currently we have three freeipa servers (1-3) on Fedora 26 (clearly need
> updating) with ipa VERSION: 4.4.4, API_VERSION: 2.215 and one new Fedora 30
> server (#4) which I just started to add with VERSION: 4.8.1, API_VERSION:
> 2.233.
>
> The reason for adding a new server before updating the others is the web
> interface warning:
>
> Warning: Only One CA Server Detected
> It is strongly recommended to keep the CA services installed on more than
> one server
>
> which I fully understand is not good, but it doesn't offer to just fix it!
>
> I suspect server #4 may be too new, failing with both
>
> ipa-replica-install --setup-ca
>
> and
>
> ipa-ca-install
>
> in a very similar way, e.g.
>
> 2019-09-26T16:18:15Z ERROR Unable to log in as uid=admin-freeipa04.services.nsa.stats.ox.ac.uk,ou=people,o=ipaca on ldap://freeipa01.services.nsa.stats.ox.ac.uk:389
> 2019-09-26T16:18:15Z DEBUG Traceback (most recent call last):
> File "/usr/lib/python3.7/site-packages/ipaserver/install/service.py", line 603, in start_creation
> run_step(full_msg, method)
> File "/usr/lib/python3.7/site-packages/ipaserver/install/service.py", line 589, in run_step
> method()
> File "/usr/lib/python3.7/site-packages/ipaserver/install/dogtaginstance.py", line 503, in setup_admin
> self.admin_dn, master_conn
> ipalib.errors.NotFound: uid=admin-freeipa04.services.nsa.stats.ox.ac.uk,ou=people,o=ipaca did not replicate to ldap://freeipa01.services.nsa.stats.ox.ac.uk:389
>
> 2019-09-26T16:18:15Z DEBUG [error] NotFound: uid=admin-freeipa04.services.nsa.stats.ox.ac.uk,ou=people,o=ipaca did not replicate to ldap://freeipa01.services.nsa.stats.ox.ac.uk:389
>
>
> which I think others have also run into.
>
> Next thought was to confirm what we had:
>
> [root@freeipa01 ~]# ipa server-find
> ---------------------
> 4 IPA servers matched
> ---------------------
> Server name: freeipa01.services.nsa.stats.ox.ac.uk F26
>
> Server name: freeipa02.services.nsa.stats.ox.ac.uk F26
>
> Server name: freeipa03.services.nsa.stats.ox.ac.uk F26
>
> Server name: freeipa04.services.nsa.stats.ox.ac.uk F30
> ----------------------------
> Number of entries returned 4
> ----------------------------
> [root@freeipa01 ~]# ipa server-role-find --role "CA server"
> ----------------------
> 4 server roles matched
> ----------------------
> Server name: freeipa01.services.nsa.stats.ox.ac.uk
> Role name: CA server
> Role status: enabled
>
> Server name: freeipa02.services.nsa.stats.ox.ac.uk
> Role name: CA server
> Role status: absent
>
> Server name: freeipa03.services.nsa.stats.ox.ac.uk
> Role name: CA server
> Role status: absent
>
> Server name: freeipa04.services.nsa.stats.ox.ac.uk
> Role name: CA server
> Role status: absent
> ----------------------------
> Number of entries returned 4
> ----------------------------
>
>
> and then find out how to change the "Role status:" to enabled, starting on
> freeipa02 but I am not sure how to achieve this, e.g.
>
>
> [root@freeipa02 ~]# ipa-ca-install
> CA is already installed on this host.
>
> true but doesn't really help. Sorry if this is very easy to do with a
> command I have totally missed.
>
> Currently I know if freeipa01 fails, client logins also fail, and I assume
> this is because it is the only CA server enabled.
>
> Work plan:
>
> 1. Enable more CA servers
>
> 2. Update Fedora 26 to 30, perhaps via 28 first if advised not to jump too
> far at once, probably updating servers #2, then #3 and finally #1.
>
> 3. Add more servers for resiliency
>
>
> Any idea how to get more CA servers enabled or any other suggestions?
>
> Many thanks
>
> Best wishes
>
> Stuart
10 months, 1 week
Re: Enabling more FreeIPA CA servers
by Fraser Tweedale
On Mon, Sep 30, 2019 at 08:19:15AM +0100, Stuart McRobert wrote:
> Dear Fraser,
>
> Thanks, I've retained the CC but will probably need to join.
>
> > I think your idea to first try creating a CA replica on F28 before
> > moving forward to F30 is a sensible thing to try.
>
> I will explore adding a F28 replica
>
> > One question though: are you on Domain Level 0 or 1?
> > (`ipa domainlevel-get`).
>
> All four servers currently report:
>
> % ipa domainlevel-get
> -----------------------
> Current domain level: 1
> -----------------------
>
> This isn't something I've custom set, and earlier I thought the original
> three servers were at level 0 with only the new F30 one at 1.
>
Thanks for confirming Stuart. This setting is not surprising and it
is the value we want. I will try to find time to carry out some
tests on f26 -> f30 replica creation later this week.
Cheers,
Fraser
> Best wishes
>
> Stuart
>
10 months, 1 week
