Custom ssl cert for freeipa docker
by Leo O
Hello Guys,
I'm would like to use custom ssl certificates for http and ldap, I saw the following:
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
But I wonder how would this be done when using freeipa in a docker/podman container. I mean the container is started with "--read-only" flag. So it's not clear to me what the correct approach here would be. I hope it's not that you have to re-build an own image with the ssl certificates every time?
Background Info: I'm using acme.sh in a VM, which creates my wildcard letsencrypt certificates and puts them on an nfs share. Freeipa should simply use that certificates for http and ldap and that's it. No renewing as this is done by the acme.sh VM itself.
7 months, 3 weeks
Visibility/access of Freeipa users to windows on trusted AD
by Francis Augusto Medeiros-Logeay
Hi,
I have searched this everywhere, but can't find it.
I want to grant access to a FreeIPA user to a Windows machine. When I
try to grant the user access on windows, adding it like
FREEIPADOMAIN\freeipauser, I get an error. There is a trust between both
domains, but every place where I see the trusted domain on Windows (for
example when configuring a GPO) I can't search for FreeIPA users.
Is this how it is supposed to be, or how can I see my FreeIPA users on
Windows the same way I see AD users on my freeipa linux clients?
Best,
Francis
--
Francis Augusto Medeiros-Logeay
Oslo, Norway
8 months, 2 weeks
Cannot get rid of a replica/agreement
by lejeczek
Hi guys.
Two masters from which third got disconnected in a "dirty"
manner.
-> $ ipa-replica-manage del midway.ccn.priv.dom
Server removal aborted:
Replication topology in suffix 'domain' is disconnected:
Topology does not allow server love.ccn.priv.dom to
replicate with servers:
midway.ccn.priv.dom
Topology does not allow server midway.ccn.priv.dom to
replicate with servers:
love.ccn.priv.dom
punch.ccn.priv.dom
Topology does not allow server punch.ccn.priv.dom to
replicate with servers:
midway.ccn.priv.dom.
-> $ ipa topologysegment-find domain
-----------------
1 segment matched
-----------------
Segment name: punch.ccn.priv.dom-to-love.ccn.priv.dom
Left node: punch.ccn.priv.dom
Right node: love.ccn.priv.dom
Connectivity: both
----------------------------
Number of entries returned 1
-> $ ipa-replica-manage del midway.ccn.priv.dom --force
ipa: WARNING:
/usr/lib/python3.6/site-packages/ipaserver/plugins/dogtag.py:1973:
The subsystem in PKIConnection.__init__() has been
deprecated
(https://www.dogtagpki.org/wiki/PKI_10.8_Python_Changes).
Updating DNS system records
Not allowed on non-leaf entry
I've tried to 'reinitialize' but without success.
Anybody care to share suggestions & thoughts?
many thanks, L.
9 months
Limiting access to GUI
by Entrepreneur AJ
Hey all,
I have a wan facing install due to many of my team operating with mobile phone hotspots whilst visiting customers.
An Issue I'm having is I want to restrict the GUI to only our admin team's IP address but editing the Apache Config with;
# webUI is now completely static, and served out of that directory
Alias /ipa/ui "/usr/share/ipa/ui"
<Directory "/usr/share/ipa/ui">
SetHandler None
AllowOverride None
Satisfy Any
Require all granted
ExpiresActive On
ExpiresDefault "access plus 1 year"
<FilesMatch "(index.html|loader.js|login.html|reset_password.html)">
ExpiresDefault "access plus 0 seconds"
</FilesMatch>
Order allow,deny
Allow from <ADMIN IP RANGE>
</Directory>
Is still allowing anyone with a browser to reach the IPA gui.
We have Keycloak in place for staff and users to update their passwords.
Any pointers? I would personally prefer to firewall it off but that effects other IPA features.
9 months, 2 weeks
Do keytabs expire?
by Ronald Wimmer
Hi,
today I found out that some entries in a keytab file seemed to have expired:
Request ticket server HTTP/mwc.linux.mydomain.at(a)LINUX.MYDOMAIN.AT kvno
4 not found in keytab; keytab is likely out of date
Fetching the keytab again with ipa-getkeytab fixed the problem. But why
is this happening? Do keytab entries expire? I have not set any custom
password or ticket policies.
Regards,
Ronald
10 months, 2 weeks
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
11 months
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
11 months, 1 week
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
11 months, 2 weeks
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
11 months, 3 weeks
