Disabled Domain fills IPA client sssd logs
by Ronald Wimmer
We do face the problem that we disabled a domain we do not need and that
this particular domain fills up sssd logs on the client side. Especially
sssd_nss.log. How could we possibly avoid this behavior?
Cheers,
Ronald
1 week, 5 days
Best practices for upgrading when running dockerized FreeIPA
by Sebastiano Pomata
Hi all,
I successfully deployed a FreeIPA installation with a master server and two replicas using podman and the container images provided on docker.io (specifically, those based on fedora 36) on RHEL 8.
Time has passed (indeed flied) and fedora 36 is now about to reach end of security support and I started thinking about upgrading to either the 4.10 freeipa based on fedora 38 or the one based on RHEL 9.
Whatever the final choice, I wonder what's the recommended path to follow? I remember having asked in the past on the freeipa IRC channel and the most common suggestion was to avoid mounting the same ipa-data directory under a new, upgraded container image, but rather creating a new replica directly based on the updated container image.
This is very sensible however now I'm faced with a practical issue on the steps to take: assuming I wanted to upgrade the master and two replicas from 4.9 to 4.10 one by one, shall I create a temporary replica under a new hostname (and same IP), delete the old replica from topology and bring its container down, then re-create a new replica with the proper previous hostname?
Or just give up on the old hostname and stick with the new one for the upgraded replica? As I manage the installation with SRV records from DNS, ditching the old name for a new one doesn't seem painful, however we have some services that rely on the LDAP hostname of the current IPA servers and would still require manual upgrade.
DNS is not managed by FreeIPA but externally on another server, which I fully control.
Hope my question is clear and somebody who dealt with upgrades more often can provide some feedback.
Thanks
Regards
2 weeks, 6 days
Help with Ghost Replica removal please.
by Nicholas Cross
I am on a long journey upgrading from a mixture of different versions of
freeipa to the lastest and i am almost there, currently on 4.10.
After removing some older replicas yesterday, a new replica had a fault and
we had to restart dirsrv.
When it came back up we saw we have ghost replicas across the whole estate
6x replicas in two locations.
Issues are reported via `cipa`
Digging into the tombstone records, i find there are not the usual
tombstone replica records but more like the below.
My question is, how do i remove these redundant records? As I believe this
is what `cipa` is counting to report the errors.
(marked with <<<<<<<<<<<<<<)
The usual things do not work:
# ipa-replica-manage -p $pass clean-ruv 15
Replica ID 15 not found
$ cat remove_ruv.ldif
dn: cn=clean 15,cn=cleanallruv,cn=tasks,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
replica-base-dn: dc=ad,dc=companyx,dc=fm
replica-id: 15
cn: clean 15
ldapmodify -Y GSSAPI -f remove_ruv.ldif
Thanks in advance.
Nick
$ ldapsearch -D "cn=Directory Manager" -w $pass -Q -o ldif-wrap=no -LLL -b
"dc=ad,dc=companyx,dc=fm"
'(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))'
dn: cn=replica,cn=dc\3Dad\2Cdc\3Dcompanyx\2Cdc\3Dfm,cn=mapping
tree,cn=config
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindDNGroup: cn=replication
managers,cn=sysaccounts,cn=etc,dc=ad,dc=companyx,dc=fm
nsDS5ReplicaBindDnGroupCheckInterval: 60
nsDS5ReplicaId: 56
nsDS5ReplicaName: a6b5640c-ad3911ed-a50980fb-6203228c
nsDS5ReplicaRoot: dc=ad,dc=companyx,dc=fm
nsDS5ReplicaType: 3
nsState:: OAAAAAAAAABSPEJkAAAAAAAAAAAAAAAA7AAAAAAAAAAGAAAAAAAAAA==
nsds5ReplicaBackoffMax: 300
nsds5ReplicaLegacyConsumer: off
nsds5ReplicaReleaseTimeout: 60
objectClass: top
objectClass: nsds5replica
objectClass: extensibleobject
nsds50ruv: {replicageneration} 5d9e2076000000040000
nsds50ruv: {replica 56 ldap://ipa006.ad.companyx.fm:389}
63ece66f000000380000 64423d4e000000380000
nsds50ruv: {replica 46 ldap://ipa005.ad.companyx.fm:389}
63dbcc200001002e0000 64423cf6000f002e0000
nsds50ruv: {replica 21 ldap://etcd0dc.ad.companyx.fm:389}
5f2d4bc1000000150000 64319ec3276200150000
nsds50ruv: {replica 48 ldap://ipa007.ad.companyx.fm:389}
63ea4e54000100300000 6442397e000a00300000
nsds50ruv: {replica 58 ldap://ipa001dc.ad.companyx.fm:389}
643d03280001003a0000 644232c00001003a0000
nsds50ruv: {replica 60 ldap://ipa002dc.ad.companyx.fm:389}
643d19680001003c0000 644232660004003c0000
nsds50ruv: {replica 62 ldap://ipa003dc.ad.companyx.fm:389}
643d491e0001003e0000 644233340000003e0000
nsds5agmtmaxcsn: dc=ad,dc=companyx,dc=fm;
ipa006.ad.companyx.fm-to-ipa003dc.ad.companyx.fm;ipa003dc.ad.companyx.fm
;389;62;644238c9000000380000
nsds5agmtmaxcsn: dc=ad,dc=companyx,dc=fm;
ipa006.ad.companyx.fm-to-ipa007.ad.companyx.fm;ipa007.ad.companyx.fm
;389;48;644238c9000000380000
nsds5agmtmaxcsn: dc=ad,dc=companyx,dc=fm;
ipa006.ad.companyx.fm-to-etcd2dc.ad.companyx.fm;etcd2dc.ad.companyx.fm;389;unavailable;64423cf6000f002e0000
<<<<<<<<<<<<<<
nsds5agmtmaxcsn: dc=ad,dc=companyx,dc=fm;
ipa006.ad.companyx.fm-to-ipa005.ad.companyx.fm;ipa005.ad.companyx.fm
;389;46;644238c9000000380000
nsruvReplicaLastModified: {replica 56 ldap://ipa006.ad.companyx.fm:389}
64423c62
nsruvReplicaLastModified: {replica 46 ldap://ipa005.ad.companyx.fm:389}
64423c0c
nsruvReplicaLastModified: {replica 21 ldap://etcd0dc.ad.companyx.fm:389}
00000000
nsruvReplicaLastModified: {replica 48 ldap://ipa007.ad.companyx.fm:389}
64423894
nsruvReplicaLastModified: {replica 58 ldap://ipa001dc.ad.companyx.fm:389}
644231da
nsruvReplicaLastModified: {replica 60 ldap://ipa002dc.ad.companyx.fm:389}
6442317a
nsruvReplicaLastModified: {replica 62 ldap://ipa003dc.ad.companyx.fm:389}
64423249
nsruvReplicaLastModified: {replica 12} 644180f7 <<<<<<<<<<<<<<
nsruvReplicaLastModified: {replica 15} 644180f7 <<<<<<<<<<<<<<
nsruvReplicaLastModified: {replica 25} 644180f7 <<<<<<<<<<<<<<
nsruvReplicaLastModified: {replica 23} 644180f7 <<<<<<<<<<<<<<
nsruvReplicaLastModified: {replica 40} 644180f7 <<<<<<<<<<<<<<
nsds5ReplicaChangeCount: 734077
nsds5replicareapactive: 0
3 weeks, 4 days
Can't access share SMB from Windows but can on macOS.
by Alan Latteri
Hello,
I have both RHEL 8 and 9 file servers that are authenticated to IPA and setup to export samba shares using the "Samba on an IdM domain member" method.
I can access these shares via smb:// on macOS without issue. When I try to access them via Windows 10 or 11, it will prompt for credentials and then reject them. The windows machines are setup standalone, no domain, no AD. I'm only trying to access the share, via //192.XXX.XXX.XX.
Below is my samba config. Any help would be greatly appreciated.
[global]
# Limit number of forked processes to avoid SMBLoris attack
max smbd processes = 1000
# Use dedicated Samba keytab. The key there must be synchronized
# with Samba tdb databases or nothing will work
dedicated keytab file = FILE:/etc/samba/samba.keytab
kerberos method = dedicated keytab
# Set up logging per machine and Samba process
log file = /var/log/samba/log.%m
log level = 1
# We force 'member server' role to allow winbind automatically
# discover what is supported by the domain controller side
server role = member server
realm = XXX.LOCAL
netbios name = NAS02
workgroup = XXX
# Local writable range for IDs not coming from IPA or trusted domains
idmap config * : range = 0 - 0
idmap config * : backend = tdb
idmap config XXX : range = 540600000 - 540799999
idmap config XXX : backend = sss
#Additional sutff for macOS
#min protocol = SMB2
vfs objects = fruit streams_xattr
ea support = yes
fruit:metadata = stream
fruit:nfs_aces = no
fruit:aapl = yes
fruit:model = MacSamba
fruit:posix_rename = yes
#fruit:veto_appledouble = no
#fruit:zero_file_id = yes
#fruit:wipe_intentionally_left_blank_rfork = yes
#fruit:delete_empty_adfiles = yes
[nas02]
path = /mnt/nas02/active
browseable = yes
read only = no
inherit acls = yes
inherit permissions = yes
1 month
ipa migrate-ds
by Tony Super
Hello,
I am trying to migrate from my an IPA server that has FIPS disabled to an IPA server that has FIPS enabled. Both the old and the new IPA will have DNS, CA, and etc.
I ran: ipa migrate-ds --bind-dn="cn=Directory Manager" --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts --group-objectclass=posixgroup --user-ignore-objectclass=mepOriginEntry --with-compat ldap://oldipa.server.com However, when I login to a client machine connected to the new IPA server, my file ownership becomes htony : nobody.
What steps have I missed within the migration process?
I've tried exporting cn=groups tree from the old IPA server into a LDIF and imported to the new IPA server, but it did not solve the problem.
For everything else, DNS, sudoers, automount, and etc, can I simply export from the old server and import into the new server?
I also have 100+ client machines, is there an easy way where I can unjoin the machines from old-ipa-server and then join to the new-ipa-server? (My infrastructure is Ansible-enabled)
Thanks in advance!
Best,
Tony
1 month
IPACertNSSTrust Error
by Jeremy Tourville
I ran a health check on my server today and received an error similar to the example from https://github.com/freeipa/freeipa-healthcheck/blob/master/README.md
My system is running FreeIPA 4.9.10
{
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertNSSTrust",
"result": "ERROR",
"kw": {
"key": "caSigningCert cert-pki-ca some-random-string-of-numbers",
"expected": "CTu,Cu,Cu",
"got": "u,u,u",
"nickname": "caSigningCert cert-pki-ca some-random-string-of-numbers",
"dbdir": "/etc/pki/pki-tomcat/alias",
"msg": "Incorrect NSS trust for {nickname} in {dbdir}. Got {got} expected {expected}"
}
}
How do I troubleshoot/fix? I presume the message is due to the extra "stuff" in the key.
1 month, 1 week
AWS Loadbalancer 2 FreeIPA servers
by Finn Fysj
I'm aware that it exists an almost identical thread (https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorah...)
However, in my case I'm only using FreeIPA as an LDAP server with GUI. I'm not using it as DNS nor as CA.
So, the only thing I should do is to generate certificate for master, replica and the loadbalancer, right?(To avoid the issues described in linked thread)
Where the certificates contains:
master: master fqdn and loadbalancer fqdn
replica: replica fqdn and loadbalancer fqdn
loadbalaner: master fqdn and replica fqdn.
Thank you for any clarification(s).
1 month, 1 week
BrowserMatch MSIE
by Finn Fysj
I see that /etc/httpd/conf.d/ssl.conf for my IPA instances includes the following lines:
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is sent or allowed to be received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is sent and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
BrowserMatch "MSIE [2-5]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
Would it be a good security practice to remove this? E.g "We do not accept MSIE 2-5 clients
1 month, 1 week
Disable anonymous access to ldap
by Mojtaba Ghahari
Is it possible to disable anonymous read access to ldap?
When I try to delete permission related to this, I got an error that this is a managed permission and cannot be deleted.
Command:
ipa permission-del "System: Read Global Configuration"
Result:
ipa: ERROR: Insufficient access: cannot delete managed permissions
Is there any functionality that may be broken by this?
1 month, 1 week
Admin account gets constantly locked
by Yavor Marinov
Hello all,
We have a really strange problem with our installation of FreeIPA 4.10. We
are using latest Alma 9.1 as OS, but the default user account admin is
getting constantly locked. After kinit-ing with different admin user and
unlocking the account it becomes available.
Another side effect of this is that WebUI starts reporting that the service
is unavailable with a popup. Once user admin is unlocked and ipa services
are restarted everything becomes available.
Can you give me some heads up what should i check (password policy
expiration is set to 90 days)
1 month, 1 week
