Recommendations for FreeIPA implemenation in existing organization
by Thomas Schneider
Hello,
I'm planning to implement FreeIPA in an existing organization that is
providing services
- DNS
- Active Directory
- LDAP
- Certificates
My question for the experts is:
What is your best practice / recommendation for implementation of
FreeIPA considering the existing services?
Should I simply *not activate* services in FreeIPA that already exist,
e.g. DNS, Certificates?
Regards
Thomas
3 years, 8 months
Looking for help to get my IPA server running again
by Lorenz Braun
Hi there,
i have been running an IPA install (4.5.0) on a CentOS 7 server for
quite a while and had some problems with it. Eventually everything got
worse and now it is not really usable anymore.
It started with someone accidentally shutting down the server. From that
point one of the services did not run anymore. Not 100% sure but i think
it was pki-tomcat. I "fixed" it temporarily by using the
'--ignore-service-failures' flag with ipactl. Everything seemed fine
until about one or two weeks ago.
Some Clients could sometimes not get kerberos tickets. I couldn't quite
figure out why.
I used 'ipa-backup --data' in hopes of restoring it on a fresh OS with
everything working again. Had to upgrade to IPA 4.6.6. It worked with
'ipa-restore --data --backend=userRoot'. 'kinit' works, but i can't use
any 'ipa ...' commands. Here an example:
```
[root@ipa01 ~]# ipa -v user-find --all
ipa: INFO: trying https://ipa01.example.com/ipa/json
ipa: INFO: [try 1]: Forwarding 'schema' to json server
'https://ipa01.example.com/ipa/json'
ipa: ERROR: No valid Negotiate header in server response
```
/var/log/httpd/error_log:
```
[Thu Jul 16 10:40:27.007724 2020] [auth_gssapi:error] [pid 2210] [client
xx.xx.xx.1:40920] GSS ERROR gss_acquire_cred[_from]() failed to get
server creds: [Unspecified GSS failure. Minor code may provide more
information ( SPNEGO cannot find mechanisms to negotiate)], referer:
https://ipa01.example.com/ipa/xml
```
/var/log/messages:
```
[...]
Jul 16 10:40:26 ipa01 gssproxy: [CID 14][2020/07/16 08:40:26]:
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-httpd",
euid: 48,socket: (null)
Jul 16 10:40:26 ipa01 gssproxy: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [
] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> time_req:
4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: BOTH
initiator_time_req: 0 acceptor_time_req: 0 )
Jul 16 10:40:26 ipa01 gssproxy: gssproxy[2408]: (OID: { 1 2 840 113554 1
2 2 }) Unspecified GSS failure. Minor code may provide more
information, Preauthentication failed
Jul 16 10:40:26 ipa01 gssproxy: GSSX_RES_ACQUIRE_CRED( status: { 851968
{ 1 2 840 113554 1 2 2 } 2529638936 "Unspecified GSS failure. Minor
code may provide more information" "Preauthentication failed" [ ] }
output_cred_handle: <Null> )
Jul 16 10:40:26 ipa01 gssproxy: [CID 14][2020/07/16 08:40:26]:
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-httpd",
euid: 48,socket: (null)
Jul 16 10:40:26 ipa01 gssproxy: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [
] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> time_req:
4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: BOTH
initiator_time_req: 0 acceptor_time_req: 0 )
Jul 16 10:40:27 ipa01 gssproxy: gssproxy[2408]: (OID: { 1 2 840 113554 1
2 2 }) Unspecified GSS failure. Minor code may provide more
information, Preauthentication failed
Jul 16 10:40:27 ipa01 gssproxy: GSSX_RES_ACQUIRE_CRED( status: { 851968
{ 1 2 840 113554 1 2 2 } 2529638936 "Unspecified GSS failure. Minor
code may provide more information" "Preauthentication failed" [ ] }
output_cred_handle: <Null> )
Jul 16 10:40:34 ipa01 [sssd[ldap_child[15047]]]: Failed to initialize
credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication
failed. Unable to create GSSAPI-encrypted LDAP connection.
[...]
```
Does anyone know how to fix this or debug it further? I still have a
snapshot of the old ipa machine if that helps.
I am also thinking about just backing up the user database (usernames
and passwords, everything else is nice but not required) and using a
fresh install with just the user data. I how much different this would
be from what i have done now to be honest.
Re-installing the clients is not much work for me, because it is well
automated and there are few clients anyway.
I hope this was not too long and convoluted. I'll be glad about any help.
Best regards
Lorenz
3 years, 8 months
certmapdata issue
by Shane Frasier
Hello,
I have users who kinit using their PIV (smartcard) certificates. Everything works great for users who happen to be "full" employees, but contractors' certificates never match.
"Full" employees have certificates issues by:
OU=DHS CA4,OU=Certification Authorities,OU=Department of Homeland Security,O=U.S. Government,C=US
Their certificates are issued to, for example:
CN=JOHN J SMITH+UID=0123456789.DHS HQ,OU=People,OU=DHS HQ,OU=Department of Homeland Security,O=U.S. Government,C=US
Contractors have certificates issued by:
OU=DHS CA4,OU=Certification Authorities,OU=Department of Homeland Security,O=U.S. Government,C=US
Their certificates are issued to, for example:
CN=MAX M MUSTERMANN (affiliate)+UID=0123456789.DHS HQ,OU=People,OU=DHS HQ,OU=Department of Homeland Security,O=U.S. Government,C=US
I have the usual certificate mapping rule:
(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
I also have a simple matching rule:
<ISSUER>O=U.S. Government
I currently have the following four certificate mapping data entries for each user:
* X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,CN=MAX M MUSTERMANN (affiliate)+UID=0123456789.DHS HQ
* X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,CN=MAX M MUSTERMANN (affiliate),UID=0123456789.DHS HQ
* X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,UID=0123456789.DHS HQ+CN=MAX M MUSTERMANN (affiliate)
* X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,UID=0123456789.DHS HQ,CN=MAX M MUSTERMANN (affiliate)
Any thoughts as to why the contractors' certificates never match? I assume it has something to do with the "(affiliate)" that appears in their CN.
Thanks,
Shane Frasier
3 years, 8 months
LDAP conflicts and ldapsubentry
by David Harvey
Dear list,
I noted from TFM
<https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...>
that conflicting values have ldapSubEntry and nsds5ReplConflict attributes,
however it only mentioned removing the latter. Should we in fact remove
ldapsubentry as well when resolving these conflicts?
For the two conflicts I had, I noted:
1. cn: ipservices was identical apart from the aforementioned attributes.
*laregly resolved but ldapsubentry still in place taking the newer version
over old
2. I had a subtly different "cn: System: Read POSIX details of SMB
services". Conflicting entries (ipaPermDefaultAttr: uid vs
ipaPermDefaultAttr: uidnumber) which I assume to be a schema change during
upgrade that borked somehow?
* I haven't actioned this one yet given the discrepancy.
Recently upgraded packages in centos which took us from 4.7.6 (IIRC) to
4.8.4.
Thanks as ever,
David
3 years, 8 months
freshly installed FreeIPA server dies
by Tony Brian Albers
Hi guys,
This is a new install, software used is:
ipa-server.x86_64 4.8.4-7.module+el8.2.0+6046+aaa49f96
389-ds-base.x86_64 1.4.2.4-8.module+el8.2.0+5959+cfcaedbd
I followed the install instructions in the documentation, and
everything went fine. I haven't added any users or groups yet.
I have a master and a replica. The master dies, but the replica seems
totally happy.
I restarted the master yesterday at 13:25. However, after a short time
running, the log files in /var/log/pki/pki-tomcat/ca/debug.. starts
filling up with java SocketExceptions like these:
2020-07-08 13:57:49 [profileChangeMonitor] SEVERE: Profile change
monitor: Caught exception: netscape.ldap.LDAPException: Server or
network error (81)
netscape.ldap.LDAPException: Server or network error (81)
at netscape.ldap.LDAPConnThread.networkError(Unknown Source)
at netscape.ldap.LDAPConnThread.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)
2020-07-08 13:57:49 [AuthorityMonitor] WARNING: AuthorityMonitor:
Failed to execute LDAP search for lightweight CAs:
netscape.ldap.LDAPException: Server or network error (81)
netscape.ldap.LDAPException: Server or network error (81)
at netscape.ldap.LDAPConnThread.networkError(Unknown Source)
at netscape.ldap.LDAPConnThread.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)
2020-07-08 13:57:49 [profileChangeMonitor] SEVERE: Unable to create
socket: java.net.SocketException: Network is unreachable (connect
failed)
java.net.SocketException: Network is unreachable (connect failed)
...
So it's pretty obvious that the LDAP server is not working properly.
In /var/log/dirsrv/slapd-YAK2-NET/errors I see:
389-Directory/1.4.2.4 B2020.121.2358
fipa001.yak2.net:636 (/etc/dirsrv/slapd-YAK2-NET)
[08/Jul/2020:13:25:36.982866396 +0200] - INFO - slapd_extract_cert - CA
CERT NAME: YAK2.NET IPA CA
[08/Jul/2020:13:25:37.002136210 +0200] - WARN - Security Initialization
- SSL alert: Sending pin request to SVRCore. You may need to run
systemd-tty-ask-password-agent to provide the password.
[08/Jul/2020:13:25:37.030257707 +0200] - INFO - slapd_extract_cert -
SERVER CERT NAME: Server-Cert
[08/Jul/2020:13:25:37.049921505 +0200] - INFO - Security Initialization
- SSL info: Enabling default cipher set.
[08/Jul/2020:13:25:37.074564197 +0200] - INFO - Security Initialization
- SSL info: Configured NSS Ciphers
[08/Jul/2020:13:25:37.091262372 +0200] - INFO - Security Initialization
- SSL info: TLS_AES_128_GCM_SHA256: enabled
...
All ciphers enabled
...
[08/Jul/2020:13:25:37.601009917 +0200] - INFO - Security Initialization
- slapd_ssl_init2 - Configured SSL version range: min: TLS1.0, ma
x: TLS1.2
[08/Jul/2020:13:25:37.616336615 +0200] - INFO - Security Initialization
- slapd_ssl_init2 - NSS adjusted SSL version range: min: TLS1.2,
max: TLS1.2
...
[08/Jul/2020:13:25:38.547791102 +0200] - NOTICE - bdb_start - Detected
Disorderly Shutdown last time Directory Server was running, recovering
database.
[08/Jul/2020:13:25:38.792474100 +0200] - ERR - attrcrypt_unwrap_key -
Failed to unwrap key for cipher AES
[08/Jul/2020:13:25:38.817182778 +0200] - ERR - attrcrypt_cipher_init -
Symmetric key failed to unwrap with the private key; Cert might have
been renewed since the key is wrapped. To recover the encrypted
contents, keep the wrapped symmetric key value.
[08/Jul/2020:13:25:38.852524974 +0200] - ERR - attrcrypt_unwrap_key -
Failed to unwrap key for cipher 3DES
[08/Jul/2020:13:25:38.871423186 +0200] - ERR - attrcrypt_cipher_init -
Symmetric key failed to unwrap with the private key; Cert might have
been renewed since the key is wrapped. To recover the encrypted
contents, keep the wrapped symmetric key value.
[08/Jul/2020:13:25:38.880537833 +0200] - ERR - attrcrypt_init - All
prepared ciphers are not available. Please disable attribute
encryption.
[08/Jul/2020:13:25:38.891681971 +0200] - ERR - attrcrypt_unwrap_key -
Failed to unwrap key for cipher AES
[08/Jul/2020:13:25:38.916694998 +0200] - ERR - attrcrypt_cipher_init -
Symmetric key failed to unwrap with the private key; Cert might have
been renewed since the key is wrapped. To recover the encrypted
contents, keep the wrapped symmetric key value.
[08/Jul/2020:13:25:38.925787580 +0200] - ERR - attrcrypt_unwrap_key -
Failed to unwrap key for cipher 3DES
[08/Jul/2020:13:25:38.934688993 +0200] - ERR - attrcrypt_cipher_init -
Symmetric key failed to unwrap with the private key; Cert might have
been renewed since the key is wrapped. To recover the encrypted
contents, keep the wrapped symmetric key value.
[08/Jul/2020:13:25:38.943696327 +0200] - ERR - attrcrypt_init - All
prepared ciphers are not available. Please disable attribute
encryption.
[08/Jul/2020:13:25:38.963177992 +0200] - ERR - schema-compat-plugin -
scheduled schema-compat-plugin tree scan in about 5 seconds after the
server startup!
[08/Jul/2020:13:25:39.005290186 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=dns,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.016002719 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=dns,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.025021142 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=keys,cn=sec,cn=dns,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.034249703 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=dns,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.043141171 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=dns,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.052203339 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=groups,cn=compat,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.061377434 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=computers,cn=compat,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.070224153 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=ng,cn=compat,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.079482188 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target ou=sudoers,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.088423317 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=users,cn=compat,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.097485949 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.106344275 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.115510556 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.124588060 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.133557279 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.142529788 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.151543892 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.160697059 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.169730169 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.178596620 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.187737945 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.200014978 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=ad,cn=etc,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.215529397 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=casigningcert cert-pki-
ca,cn=ca_renewal,cn=ipa,cn=etc,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.223802735 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=casigningcert cert-pki-
ca,cn=ca_renewal,cn=ipa,cn=etc,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.223802735 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=casigningcert cert-pki-
ca,cn=ca_renewal,cn=ipa,cn=etc,dc=yak2,dc=net does not exist
[08/Jul/2020:13:25:39.295259710 +0200] - WARN - NSACLPlugin - acl_parse
- The ACL target cn=automember rebuild membership,cn=tasks,cn=config
does not exist
[08/Jul/2020:13:25:39.307599195 +0200] - ERR - cos-plugin -
cos_dn_defs_cb - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=yak2,dc=net--no CoS Templates found, which should
be added before the CoS Definition.
...
[08/Jul/2020:13:25:39.414188379 +0200] - WARN - NSMMReplicationPlugin -
replica_check_for_data_reload - Disorderly shutdown for replica
dc=yak2,dc=net. Check if DB RUV needs to be updated
[08/Jul/2020:13:25:39.422657691 +0200] - ERR - set_krb5_creds - Could
not get initial credentials for principal [
ldap/fipa001.yak2.net(a)YAK2.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]:
-1765328228 (Cannot contact any KDC for requested realm)
[08/Jul/2020:13:25:39.431578492 +0200] - WARN - NSMMReplicationPlugin -
replica_check_for_data_reload - Disorderly shutdown for replica
o=ipaca. Check if DB RUV needs to be updated
[08/Jul/2020:13:25:39.441463670 +0200] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=caTofipa002.yak2.net" (fipa002:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
[08/Jul/2020:13:25:39.458768924 +0200] - ERR - set_krb5_creds - Could
not get initial credentials for principal [
ldap/fipa001.yak2.net(a)YAK2.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]:
-1765328228 (Cannot contact any KDC for requested realm)
[08/Jul/2020:13:25:39.477747370 +0200] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=meTofipa002.yak2.net" (fipa002:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
[08/Jul/2020:13:25:39.494528440 +0200] - INFO - slapd_daemon - slapd
started. Listening on All Interfaces port 389 for LDAP requests
[08/Jul/2020:13:25:39.503748199 +0200] - INFO - slapd_daemon -
Listening on All Interfaces port 636 for LDAPS requests
[08/Jul/2020:13:25:39.512913530 +0200] - INFO - slapd_daemon -
Listening on /var/run/slapd-YAK2-NET.socket for LDAPI requests
[08/Jul/2020:13:25:39.521834655 +0200] - ERR - schema-compat-plugin -
schema-compat-plugin tree scan will start in about 5 seconds!
[08/Jul/2020:13:25:42.619282707 +0200] - ERR - set_krb5_creds - Could
not get initial credentials for principal [
ldap/fipa001.yak2.net(a)YAK2.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]:
-1765328228 (Cannot contact any KDC for requested realm)
[08/Jul/2020:13:25:42.660769148 +0200] - ERR - set_krb5_creds - Could
not get initial credentials for principal [
ldap/fipa001.yak2.net(a)YAK2.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]:
-1765328228 (Cannot contact any KDC for requested realm)
[08/Jul/2020:13:25:44.517541271 +0200] - ERR - schema-compat-plugin -
warning: no entries set up under ou=sudoers,dc=yak2,dc=net
[08/Jul/2020:13:25:44.570564330 +0200] - ERR - schema-compat-plugin -
warning: no entries set up under cn=ng, cn=compat,dc=yak2,dc=net
[08/Jul/2020:13:25:44.614807034 +0200] - ERR - schema-compat-plugin -
warning: no entries set up under cn=computers, cn=compat,dc=yak2,dc=net
[08/Jul/2020:13:25:44.635448724 +0200] - ERR - schema-compat-plugin -
Finished plugin initialization.
[08/Jul/2020:13:25:48.807433248 +0200] - INFO - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=meTofipa002.yak2.net" (fipa002:389):
Replication bind with GSSAPI auth resumed
[08/Jul/2020:13:25:48.853993542 +0200] - INFO - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=caTofipa002.yak2.net" (fipa002:389):
Replication bind with GSSAPI auth resumed
[08/Jul/2020:15:00:49.240767214 +0200] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=caTofipa002.yak2.net" (fipa002:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
[09/Jul/2020:07:42:10.753040947 +0200] - INFO - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=caTofipa002.yak2.net" (fipa002:389):
Replication bind with GSSAPI auth resumed
The log files grow to huge sizes very quickly and fills up the /var
filesystem which stops the server.
It's not clear to me why this is happening, any advice and tips to get
it fixed are appreciated.
/tony
--
Tony Albers - Systems Architect - IT Development
Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark
Tel: +45 2566 2383 - CVR/SE: 2898 8842 - EAN: 5798000792142
3 years, 8 months
OTP Radius 5 seconds timeout
by Sergiy Genyuk
Hello
I have setup radius proxy (DUO) and associate user with it. Everything works except radius
timeout. It is 5 seconds and you have to be blazing fast to push the button :-)
I did adjust radius timeout in freeipa to 30 seconds but it is still 5 seconds. As well I
have tried a trick with krb.conf [otp] settings, same still 5 seconds.
Please point me to proper way to change radius timeout.
Tested on Centos 8. Freeipa 4.8.4
ipa radiusproxy-find
-----------------------------
1 RADIUS proxy server matched
-----------------------------
RADIUS proxy server name: duo2
Server: x.x.x.x
Timeout: 30
Retries: 0
----------------------------
Number of entries returned 1
----------------------------
Thank you.
Sergiy
3 years, 8 months
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 years, 8 months
It ain't easy to dig a user's last login time info out of IdM/FreeIPA
by White, Daniel E. (GSFC-770.0)[NICS]
I want to get createtimestamp, krbLastSuccessfulAuth, and krbLastPwdChange for all active users
The "ipa user-find" or "ipa user-show" commands only give krbLastPwdChange and failed login count/date
The "ipa user-status" command shows "Last successful authentication", but it has to be run for each user
I found this suggestion
https://www.redhat.com/archives/freeipa-users/2016-May/msg00213.html
Could you use ldapsearch?
# ldapsearch -Y GSSAPI -b "cn=users,cn=accounts,dc=rhel72" createtimestamp krbLastSuccessfulAuth
and tried it adding in krbLastPwdChange, and using a service account as described here
https://www.freeipa.org/page/HowTo/LDAP#System_Accounts
but it did not return any krbLastSuccessfulAuth values.
A bit of tinkering revealed that I have to use the Directory Manager to get back the krbLastSuccessfulAuth.
Is it possible to tweak the service account to allow it to read krbLastSuccessfulAuth ?
______________________________________________________________________________________________
Daniel E. White
daniel.e.white(a)nasa.gov
NICS Linux Engineer
NASA Goddard Space Flight Center
8800 Greenbelt Road
Building 14, Room E175
Greenbelt, MD 20771
Office: (301) 286-6919
Mobile: (240) 513-5290
3 years, 8 months