[WARN] Please refrain from installing RhSA-2021:5082 yet
by Alexander Bokovoy
Hi,
https://access.redhat.com/errata/RHSA-2021:5082 was published this
morning for RHEL 8.5.z as a security update to fix a number of issues in
Samba.
PLEASE DO NOT UPGRADE RHEL IdM SERVERS YET!
This erratum will need to be installed together with a related erratum
for RHEL IdM which is not out yet (ongoing final tests). There is an ABI
change and also smb.conf configuration change that will not be accepted
by the old RHEL IdM, leading to a failure to recover from the upgrade.
The new RHEL IdM erratum is coming out either today or in couple days.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
2 years, 4 months
Making use of ipa-user-mod --auth-user-type=hardened
by Sam Morris
I was wondering what the purpose of 'ipa user-mod --auth-user-type=hardened' was. In the web UI the option is labelled "Hardened Password (by SPAKE or FAST)".
What I found (by setting KRB5_TRACE=/dev/stderr) was that without setting this option, kinit already opportunistically uses SPAKE:
$ kinit
[..]
[1503880] 1639651033.064871: Received error from KDC: -1765328359/Additional pre-authentication required
[1503880] 1639651033.064874: Preauthenticating using KDC method data
[1503880] 1639651033.064875: Processing preauth types: PA-PK-AS-REQ (16), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-SPAKE (151), PA-ENC-TIMESTAMP (2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133)
[1503880] 1639651033.064876: Selected etype info: etype aes256-cts, salt "xxx", params ""
[1503880] 1639651033.064877: Received cookie: xxx
[1503880] 1639651033.064878: PKINIT client has no configured identity; giving up
[1503880] 1639651033.064879: Preauth module pkinit (147) (info) returned: 0/Success
[1503880] 1639651033.064880: PKINIT client received freshness token from KDC
[1503880] 1639651033.064881: Preauth module pkinit (150) (info) returned: 0/Success
[1503880] 1639651033.064882: PKINIT client has no configured identity; giving up
[1503880] 1639651033.064883: Preauth module pkinit (16) (real) returned: 22/Invalid argument
[1503880] 1639651033.064884: SPAKE challenge received with group 1, pubkey xxx
Password for user(a)IPA.EXAMPLE.QQ': ^C
[1503880] 1639651047.197022: Preauth module spake (151) (real) returned: -1765328252/Password read interrupted
kinit: Password read interrupted while getting initial credentials
So far so good.
The client can be forced to do so by setting 'disable_encrypted_timestamp = true' for the realm in krb5.conf. But krb5.conf(5) remarks, "This flag does not prevent the KDC from offering encrypted timestamp."
It seems like the 'ipa user-mod --auth-user-type=hardened' might be a way to enforce the use of SPAKE/FAST on the server side, but once that is set on a user, the client doesn't seem to use SPAKE, it just gives up:
$ kinit
[...]
[1504024] 1639651111.830018: Received error from KDC: -1765328359/Additional pre-authentication required
[1504024] 1639651111.830021: Preauthenticating using KDC method data
[1504024] 1639651111.830022: Processing preauth types: PA-PK-AS-REQ (16), PA-FX-FAST (136), PA-PKINIT-KX (147), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133)
[1504024] 1639651111.830023: Received cookie: xxx
[1504024] 1639651111.830024: PKINIT client has no configured identity; giving up
[1504024] 1639651111.830025: Preauth module pkinit (147) (info) returned: 0/Success
[1504024] 1639651111.830026: PKINIT client received freshness token from KDC
[1504024] 1639651111.830027: Preauth module pkinit (150) (info) returned: 0/Success
[1504024] 1639651111.830028: PKINIT client has no configured identity; giving up
[1504024] 1639651111.830029: Preauth module pkinit (16) (real) returned: 22/Invalid argument
kinit: Pre-authentication failed: Invalid argument while getting initial credentials
The 'hardened' option also seems to break FAST:
$ kinit -c /tmp/blah -n && kinit -T /tmp/blah
[...]
[1504775] 1639652353.929814: Using FAST due to armor ccache negotiation result
[1504775] 1639652353.929815: Getting credentials WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS -> krbtgt/IPA.EXAMPLE.QQ(a)IPA.EXAMPLE.QQ using ccache FILE:/tmp/blah
[1504775] 1639652353.929816: Retrieving WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS -> krbtgt/IPA.EXAMPLE.QQ(a)IPA.EXAMPLE.QQ from FILE:/tmp/blah with result: 0/Success
[1504775] 1639652353.929817: Armor ccache sesion key: aes256-cts/0286
[1504775] 1639652353.929819: Creating authenticator for WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS -> krbtgt/IPA.EXAMPLE.QQ(a)IPA.EXAMPLE.QQ , seqnum 0, subkey aes256-cts/12F1, session key aes256-cts/0286
[1504775] 1639652353.929821: FAST armor key: aes256-cts/0BB2
[1504775] 1639652353.929823: Sending unauthenticated request
[1504775] 1639652353.929824: Encoding request body and padata into FAST request
[...]
[1504775] 1639652353.929829: Received error from KDC: -1765328359/Additional pre-authentication required
[1504775] 1639652353.929830: Decoding FAST response
[1504775] 1639652353.929833: Preauthenticating using KDC method data
[1504775] 1639652353.929834: Processing preauth types: PA-PK-AS-REQ (16), PA-FX-FAST (136), PA-PKINIT-KX (147), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133), PA-FX-ERROR (137)
[1504775] 1639652353.929835: Received cookie: MIT
[1504775] 1639652353.929836: PKINIT client has no configured identity; giving up
[1504775] 1639652353.929837: Preauth module pkinit (147) (info) returned: 0/Success
[1504775] 1639652353.929838: PKINIT client received freshness token from KDC
[1504775] 1639652353.929839: Preauth module pkinit (150) (info) returned: 0/Success
[1504775] 1639652353.929840: PKINIT client has no configured identity; giving up
[1504775] 1639652353.929841: Preauth module pkinit (16) (real) returned: 22/Invalid argument
kinit: Pre-authentication failed: Invalid argument while getting initial credentials
Documentation for the meaning of the hardened setting is a bit thin... can anyone fill me in?
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
2 years, 4 months
FreeIPA logs retention Period
by GAURAV Pande
Hi Team ,
Could you please help me understand or tell what is the log retention period for FreeIPA ? Couldnt get a clean/clear answer to this anywhere .How can we find out this information . Thanks
2 years, 4 months
ldap_use_tokengroups
by Ronald Wimmer
I do not understand the impact of this setting when it comes to AD user
lookup performance. Will setting it to FALSE improve performance?
Cheers,
Ronald
2 years, 4 months
/var/lib/sss/pubconf/krb5.include.d/domain_realm_domain_name file, what for?
by tizo
Just another problem of my lab about IPA trusting AD (but very close to the
end). We have this trust relation between IPA and AD. The IPA server is
installed on a Rocky Linux 8, and its domain is idmpru.xx.xx. The AD server
is a Samba AD DC 4.14 installed on a Rocky Linux 8 too, and its domain is
adtest.xx.xx.
Everything is working pretty well right now: AD users can login to Windows
clients (joined to AD domain), and can also login to Ubuntu clients (joined
to IPA domain). Besides, users in Windows clients can mount samba shares
that are configured in another server, a file server. This file server
(smbshare.adtest.xx.xx) is joined to both IPA and AD domains, and the
shares are also configured as NFS (nfsv4) exports (to let users using
Ubuntu clients mount them over NFS). Before configuring automount, I was
testing to mount one of the exports from Ubuntu with root user (as I have
tried in others IPA installations without problem), as follows:
# mount -t nfs -o vers=4,sec=krb5p smbshare.adtest.xx.xx:/prueba_share
/tmp/pru/
mount.nfs: access denied by server while mounting
smbshare.adtest.xx.xx:/prueba_share
After several tests and investigation, I could determine that the file
/var/lib/sss/pubconf/krb5.include.d/domain_realm_idmpru_xx_xx was causing
the problem. If I delete it, the previous command works all right. But
after rebooting the Ubuntu client, the file is regenerated again.
So I was wondering what this file is for, if I can delete it without any
problem, and, in that case, how to avoid it being regenerated. The content
of it is:
[domain_realm]
.adtest.xx.xx = ADTEST.XX.XX
adtest.xx.xx = ADTEST.XX.XX
[capaths]
ADTEST.XX.XX = {
IDMPRU.XX.XX = ADTEST.XX.XX
}
IDMPRU.XX.XX = {
ADTEST.XX.XX = ADTEST.XX.XX
}
Thanks very much,
tizo
2 years, 4 months
Reverse lookup Issue
by Kathy Zhu
Hi List,
I created a PTR record "90.91" in "0.10.inaddr.arpa." zone via GUI, then
found:
1, I can see the record via GUI
2, When I looked it up on the command line, I got "not found: 3(NXDOMAIN)".
3, Its dn is not in "ldapsearch -Y GSSAPI -b
idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com"
output.
Above 3 explained why the record could not be resolved. However, why does
this happen? I can see the record in GUI, where is this record?
I created more PTR records for testing, they are all the same way - can be
seen in GUI, but not resolvable and not in ldapsearch output.
Any idea for me to troubleshoot this?
Many thanks.
Kathy
2 years, 4 months
Error replacing a replica with CentOS Stream 9
by Antoine Gatineau
Hello,
I have currently a 2 node cluster running on CentOS Stream 8. In order to upgrade to CentOS 9, I have removed one of the replica from the
configuration, installed a fresh centos stream 9 and run ipa-replica-install.
It fails with this error (full log attached):
[22/29]: Importing RA key
Error storing key "keys/ra/ipaCert": CalledProcessError(Command ['/usr/libexec/ipa/custodia/ipa-custodia-ra-agent', '--import', '-']
returned non-zero exit status 1: 'Traceback (most recent call last):\n File "/usr/libexec/ipa/custodia/ipa-custodia-ra-agent", line 8, in
<module>\n main(ra_agent_parser())\n File "/usr/lib/python3.9/site-packages/ipaserver/secrets/handlers/pemfile.py", line 114, in main\n
common.main(parser, export_key, import_key)\n File "/usr/lib/python3.9/site-packages/ipaserver/secrets/handlers/common.py", line 73, in
main\n func(args, tmpdir, **kwargs)\n File "/usr/lib/python3.9/site-packages/ipaserver/secrets/handlers/pemfile.py", line 69, in
import_key\n ipautil.run(cmd, umask=0o027)\n File "/usr/lib/python3.9/site-packages/ipapython/ipautil.py", line 598, in run\n raise
CalledProcessError(\nipapython.ipautil.CalledProcessError: CalledProcessError(Command [\'/usr/bin/openssl\', \'pkcs12\', \'-in\',
\'/tmp/tmp7jrs5dqp/import.p12\', \'-clcerts\', \'-nokeys\', \'-out\', \'/var/lib/ipa/ra-agent.pem\', \'-password\',
\'file:/tmp/tmp7jrs5dqp/passwd\'] returned non-zero exit status 1: \'Error outputting keys and
certificates\\n80EB2D6B5D7F0000:error:0308010C:digital envelope
routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:346:Global default library context, Algorithm (RC2-40-CBC : 0),
Properties ()\\n\')\n')
[error] FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/ipa/ra-agent.key'
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
What can I do to make this upgrade work?
Looks like an unsupported algorithm for the RA key. I tried "sudo update-crypto-policies --set LEGACY" without success.
Thank you
2 years, 4 months
master/replica dnssec 'sending notifies' back&forth forever??
by Harry G. Coin
In a master/replica freeipa setup with DNSSEC -- is it normal the
"sending notifies" happens forever?
It would appear the master sends a notify for a zone, the replica gets
it, sees an updated SOA, updates itself, sends a notify to the master,
which sees a higher SOA, updates itself, sends a notify to the replica
.. again and again forever, and once for each zone.
How can this be avoided?
Thanks
Harry Coin
2 years, 4 months
Re: how to get xrdp to work with ipa users
by Rob Verduijn
Hi all,
Sorry for the reply to an ancient post.
But I thought I share how I finally managed to get xrdp to play nice with
freeipa.
The solution was rather simple.
When in ipa allow_all policy is disabled.
Add xrdep-sesman to the hbac-services then add the service to the
hbac-policy that allows desktop access.
after that you can login with an ipa user via xrdp
this even works for ad-domain users when you have configured a trust and
mapped all the required groups.
Rob
2 years, 4 months
Replication broken after upgrade
by Serge Krawczenko
Hello there,
Something went wrong after recent yum update (CentOS 7)
The current version is 4.6.8-5.el7.centos.9
I have two FreeIPA replicas and one Active Directory agreement (winsync)
Here what i'm getting from cn=replica....cn=mapping tree,cn=config
nsds5replicaLastUpdateStart: 19700101000000Z
nsds5replicaLastUpdateEnd: 19700101000000Z
nsds5replicaLastInitStart: 19700101000000Z
nsds5replicaLastInitEnd: 19700101000000Z
This is for both agreements, however winsync is still alive somehow.
Replication to the second FreeIPA node no longer works, and
when trying to re-initialize, here's what i'm getting:
ipa-replica-manage re-initialize --from=<node0> --verbose
Traceback (most recent call last):
File "/sbin/ipa-replica-manage", line 1624, in <module>
main(options, args)
File "/sbin/ipa-replica-manage", line 1567, in main
options.nolookup)
File "/sbin/ipa-replica-manage", line 1220, in re_initialize
repl.initialize_replication(agreement.dn, repl.conn)
File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 1358, in initialize_replication
conn.modify_s(dn, mod)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 792,
in modify_s
return self.conn.modify_s(dn, modlist)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 357,
in modify_s
return self.result(msgid,all=1,timeout=self.timeout)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 458,
in result
resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 462,
in result2
resp_type, resp_data, resp_msgid, resp_ctrls =
self.result3(msgid,all,timeout)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 469,
in result3
resp_ctrl_classes=resp_ctrl_classes
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 476,
in result4
ldap_result =
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
_ldap_call
result = func(*args,**kwargs)
TYPE_OR_VALUE_EXISTS: {'desc': 'Type or value exists'}
Unexpected error: {'desc': 'Type or value exists'}
I feel that the exception is related to time set to 19700101000000Z or some
other cn=config parameter.
Another suspicious thing which may be related is:
Running on node0:
ipa-replica-manage list -v <node1>
Failed to get data from 'node1': Insufficient access: SASL(-1): generic
failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
more information (Server krbtgt/<something unknown here> not found in
Kerberos database)
Any advice on how to fix without rebuilding everything ?
Thank you
2 years, 4 months
