We're adding FreeIPA to an immutable, often rotated environment (AWS ECS Hosts). These hosts are spun up and down at least daily. Is there a way to check FreeIPA to see when a host has last communicated with the FreeIPA Cluster? I'd like to use this information to auto-delete hosts that have not reported in from the FreeIPA host list.
I migrated an Ubuntu 20.04 client from NIS authentication to an
AlmaLinux 9 IdM domain. I purged the NIS package, installed the
freeipa-client, successfully enrolled it into the domain and now when I
login via ssh, I get these messages:
groups: cannot find name for group ID 1762200513
groups: cannot find name for group ID 1762213360
groups: cannot find name for group ID 1762225405
groups: cannot find name for group ID 1762243097
groups: cannot find name for group ID 1762243100
groups: cannot find name for group ID 1762263161
groups: cannot find name for group ID 1762313267
groups: cannot find name for group ID 1762313342
groups: cannot find name for group ID 1762313405
groups: cannot find name for group ID 1762358745
I can lookup the group names from an idm server. Also, I think this
groups lookup problem is the cause of slow logins on this Ubuntu
On other clients, I get similar messages when I use the "groups"
command to see which groups I'm a member of.
I've never experienced this before in an idm environment. What's
causing the issue?
I've got a few colleagues running Debian 10 or 11 on a laptop. Their account
is managed by FreeIPA in the office. On first-time login their laptop is
wired to the office lan.
When they are in home office they have a VPN connection (IPsec, wireguard
or openvpn) to the office, but since both wlan and VPN are usually activated
by Network Manager *after* login time I wonder what needs to be done to
update the login information cached by sssd, esp if the user has changed his
login password in the FreeIPA web interface?
By now I tried
service restart sssd
This did not help. kinit accepts the new password, of course, but it doesn't
update the cache, nor do the others.
Important point is that the user doesn't lose his cached entry, anyway.
Coming to the office just to register his new password is not an optiom.
Every helpful hint is highly appreciated
we have a three nodes FreeIPA 4.6.8 installation with third part
certificate (https / dirsrv). This certificate has expired and when I
try to follow the
ipa-cacert-manage install ...
ipa-certupdate I get the error: "cannot connect to
https://ipaserver/ipa/json : [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed (_ssl.c:618)"
I suppose that this is due to the fact that https connection is blocked
for expired certificate which I can't renew.
Is there a way to bypass this?
I've tried to set a date on the server previous than the expiring one of
the cert, but I get an SASL/GSSAPI error (even if I renew admin ticket).
I was thinking to regenerate /etc/httpd/alias/cert8.db,key3.db with new
cert/key but I don't know how
I don't see a direct option that would allow the auto creation of a
home directory in a different location if the default home directory
provided by autofs isn't available for one reason or another. Is there
a workaround that could let me do that? I'm thinking that maybe I could
do something with pam, but I don't know where to start with that.
Thanks in advance for any tips.
I have an IPA clients that has both IPv4 and IPv6 addresses. One of the
IPA client is in the office and hence can reach the IPA server on both IPv4
and IPv6. However, the client outside the LAN can only reach the IPA server
I was able to enroll the external client fine over IPv6 and from the logs,
all clean. However, when I attempted to ssh, its not able to retreave the
user from IPA. The client in the office works fine. I can also make for
example LDAP queries and they work over IPv6 fine. It looks like kerberos
is somehow however using IPv4. I reached this conclusion after taking a
tcpdump when attempting to ssh to the server and the kerberos traffic from
the client to IPA is on IPv4.
What would I need to do on the IPA client for it to prefer IPv6? I am
aware I could remove IPv4 address from DNS, but that would break any
communication from IPv4 only systems. Any assistance would be appreaciated.
[william@ansible ~]$ ssh root(a)mars.external.example.com
Last login: Mon Jan 7 17:19:49 2019 from 18.104.22.168
[root@mars ~]# kinit admin
kinit: Cannot contact any KDC for realm 'EXTERNAL.EXAMPLE.COM
<http://external.example.com/>' while getting initial credentials
[root@mars ~]# ldapsearch -x -b
cn=ftp,cn=groups,cn=compat,dc=external,dc=example,dc=com | tail -n 4
result: 0 Success
# numResponses: 2
# numEntries: 1
[root@mars ~]# cat /etc/resolv.conf
as you have probably noticed in a thread we had with Leo on
freeipa-users@ about FreeIPA plugin development, we hadn't had
consistency in handling boolean types between LDAP and IPA Python API
level. A change is coming that would make 'native' boolean types used in
both worlds. If your plugins rely on Bool() parameter handling in
FreeIPA, your code might be affected. If your scripts using output of
IPA API rely on case-sensitive output, you might need to adjust your
If not, you can skip this email.
Pull request https://github.com/freeipa/freeipa/pull/6294 turns handling
of boolean types to be native to each side:
- in LDAP, TRUE and FALSE strings used to represent the values
- in Python, native True and False constants of bool type will be used
to represent an LDAP boolean.
Prior to PR#6294, when an LDAP attribute with a boolean syntax was read
from LDAP, its representation in IPA Python code was either 'TRUE'
or 'FALSE' string. This created a bit of inconvenience:
- Python code had to explicitly compare a value to 'TRUE' or 'FALSE',
would be enough
'FALSE', 1, 0, true, false, none in every place where a boolean type
would be enough
After PR#6294 is merged, IPA Python code will use Python bool type.
JSON-RPC response to an IPA API command request would produce a simple
'true' or 'false' instead of ["TRUE"] or ["FALSE"] elements. This means,
for example, that in the following command
ipa dnszone-show ipa.test
one would get
and the output of 'ipa dnszone-show ipa.test' would have 'True' instead
of 'TRUE' (and False instead of 'FALSE'):
$ ipa dnszone-show ipa.test
Zone name: ipa.test.
Active zone: True
Authoritative nameserver: idm.ipa.test.
Administrator e-mail address: hostmaster.ipa.test.
SOA serial: 1654159048
SOA refresh: 3600
SOA retry: 900
SOA expire: 1209600
SOA minimum: 3600
BIND update policy: grant IPA.TEST krb5-self * A; grant IPA.TEST krb5-self * AAAA; grant IPA.TEST krb5-self * SSHFP;
Dynamic update: True
Allow query: any;
Allow transfer: none;
If your scripts rely on the case-sensitive output, you'd need to fix
them. IPA tools already able to handle the changes so they are
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland