cache invalidation dilema on the clients
by iulian roman
Hello,
I tried for some time to understand how the cache invalidation works on the clients, and I have to admit that I am even more confused that when I started, therefore I would like to ask if there is someone who can either explain or point me to the relevant documentation.
I'll describe bellow the situation I am currently facing:
PHASE 1
- RedHat Idm with AD trust configured (non-posix)
- override the UID of AD users in Idm
- on the clients run the id <username> ; the correct (overwritten ) UID and an auto-generated GID is displayed
PHASE 2
- overwrite the GID as well on Idm
- on the clients still the old auto-generated GID is displayed (after sss_cache -E and restart of sssd) when I run id <username>
- remove everything in /var/lib/sss/db , restart sssd and run id <username> - no user found
- getent group <username> - new overwritten GID is displayed
- id <username> displays the correct UID and GID
For the users who are not in cache, restarting sssd seems to be enough (although I did not test if thoroughly).
My question is :
What do I have to do on the client in order to have the latest information from the Idm Override ? Apparently sss_cache -E and restart ssssd is not enough .
Do we always need to remove everything in /var/lib/sss/db in order to have the latest information from the server ?
2 years, 3 months
dns of two out of three masters not up to date
by Kees Bakker
Hey,
Recently I discovered that the nameservers of two out the three IPA
masters (replicas) are
not responding with up-to-date information.
Our setup has three masters. Each is configured as nameserver. Most of
the time I use
one as the main master when I modify DNS entries. We also have a DHCP
server that
sends updates to that "main" master.
What I now discovered is that updates are not available when clients use
the two
other masters.
On all three masters the DNS record is present when I use local
ldapsearch [1]. But with dig
the record is only present on one master.
If I restart the nameserver it then has all records available.
What would be the best method to find out what is wrong?
BTW. There are two things that changed recently. I mention this in case
it rings a bell.
1. one master was re-installed with CentOS 8 Stream. An other CentOS8
master was added
a few weeks ago.
2. our nameservers don't have connection to the Internet any more. So,
root servers cannot
be found.
[1] by local ldapsearch I mean doing a command like this:
ldapsearch -H ldapi://%2fvar%2frun%2f...
--
Kees
2 years, 3 months
CentOS 8 master missing plugins?
by Kees Bakker
Hey,
We have three masters. One is CentOS 7, the other two are CentOS 8 Stream.
I'm seeing many plugins on the CentOS 7 in cn=plugins,cn=config (about 388
entries)
But on the CentOS 8 systems there are very few plugins (about 30 entries).
Is that normal?
BTW. I struggling with nameservers not being updated (see thread:
"dns of two out of three masters not up to date"). I'm not making any
progress with that.
--
Kees
2 years, 3 months
Password avability before change
by Karim Bourenane
Hello Team
I have a small question, about a new password reseted.
I have into policy password:
Min availability 1 days and max 90 days
That means, if I reset a password, the temporary is available 24h ?
Can you confirm?
FreeIPA : 4.6.5
Bien à vous
Mr Karim Bourenane
+33686464439
+32 493 86 63 54
2 years, 3 months
Hidden replica ipa-healthcheck error ADTRUST service is not enabled
by Duncan Mortimer
Hi,
We have a three node Centos 8 IPA domain which we upgraded from Centos 8.3 to 8.4 (IPA version 4.9.2) yesterday. This appeared to succeed without issue, with clients continuing to operate as expected. To give us confidence that all was well we ran ipa-healthcheck on each node post upgrade and this found no issues on our two client facing servers ipa0 and ipa1 but on the third machine, ipa2, which is configured as a hidden replica (and is used to take disaster recovery backups) we received the following error:
[
{
"source": "ipahealthcheck.ipa.trust",
"check": "IPATrustControllerServiceCheck",
"result": "ERROR",
"uuid": "f5d524a3-43c3-4320-92cb-c984727243d9",
"when": "20210624085009Z",
"duration": "0.000512",
"kw": {
"key": "ADTRUST",
"msg": "{key} service is not enabled"
}
}
]
We have Samba services setup for Centos based SMB file sharing - there is no Active Directory install on our network.
Is this error a concern or is it a consequence of being a hidden replica. If it is a problem, how might we go about fixing the issue? As a first step I've tried re-running ipa-adtrust and this didn't seem to need to make any changes:
The log file for this installation can be found in /var/log/ipaserver-adtrust-install.log
==============================================================================
This program will setup components needed to establish trust to AD domains for
the IPA Server.
This includes:
* Configure Samba
* Add trust related objects to IPA LDAP server
To accept the default shown in brackets, press the Enter key.
Configuring cross-realm trusts for IPA server requires password for user 'admin'.
This user is a regular system account used for IPA server administration.
admin password:
IPA generated smb.conf detected.
Overwrite smb.conf? [no]: yes
The following operations may take some minutes to complete.
Please wait until the prompt is returned.
Configuring CIFS
[1/24]: validate server hostname
[2/24]: stopping smbd
[3/24]: creating samba domain object
Samba domain object already exists
[4/24]: retrieve local idmap range
[5/24]: writing samba config file
[6/24]: creating samba config registry
[7/24]: adding cifs Kerberos principal
[8/24]: adding cifs and host Kerberos principals to the adtrust agents group
[9/24]: check for cifs services defined on other replicas
[10/24]: adding cifs principal to S4U2Proxy targets
cifs principal already targeted, nothing to do.
[11/24]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
[12/24]: adding RID bases
RID bases already set, nothing to do
[13/24]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
[14/24]: activating CLDAP plugin
CLDAP plugin already configured, nothing to do
[15/24]: activating sidgen task
Sidgen task plugin already configured, nothing to do
[16/24]: map BUILTIN\Guests to nobody group
[17/24]: configuring smbd to start on boot
[18/24]: enabling trusted domains support for older clients via Schema Compatibility plugin
[19/24]: restarting Directory Server to take MS PAC and LDAP plugins changes into account
[20/24]: adding fallback group
Fallback group already set, nothing to do
[21/24]: adding Default Trust View
Default Trust View already exists.
[22/24]: setting SELinux booleans
[23/24]: starting CIFS services
[24/24]: restarting smbd
Done configuring CIFS.
=============================================================================
Setup complete
You must make sure these network ports are open:
TCP Ports:
* 135: epmap
* 138: netbios-dgm
* 139: netbios-ssn
* 445: microsoft-ds
* 1024..1300: epmap listener range
* 3268: msft-gc
UDP Ports:
* 138: netbios-dgm
* 139: netbios-ssn
* 389: (C)LDAP
* 445: microsoft-ds
See the ipa-adtrust-install(1) man page for more details
=============================================================================
But there is no change in ipahealthcheck output.
Regards,
Duncan
--
Duncan Mortimer
2 years, 3 months
FreeIPA w. letsencrypt for HTTPS/LDAP failing to communicate with itself
by Chris Moody
Hello folks.
Hopefully I'm just missing something face-palm level obvious, but I am
running into some trouble when interfacing with my CA functionality on
an IPA server cluster. My attempts at scouring all my saved prior-comms
from the mailing-list as well as several search-engines are not
enchanting me with much clue.
It appears that my need for the LetsEncrypt certs for the user-facing
Web-UI and LDAPs components are causing IPA to dis-trust itself.
===
4-node cluster - Ubuntu19.10
(all nodes currently fully updated/patched via the official Ubuntu repos)
===
ipa --version
VERSION: 4.8.1, API_VERSION: 2.233
===
running letsencrypt certificates successfully for HTTPs & LDAPs connectivity
===
These 4-nodes are all happily running and replicating betwixt each
other. LDAPs is functioning great and many linux systems are able to
all join as freeipa-clients. Users and groups are replicating and being
used elegantly for many LDAP-based authentication/authorization needs.
Overall, for these nodes, life is good.
Where I'm running into trouble is in finally wanting to leverage
certificate issuance on a per-user basis. End goal is integrating
things like yubikeys, user-cert auth, and so on.
In the UI, when I enter a user's account and select Actions->New
Certificate, I am able to successfully issue the couple prompted
'certutil' commands to generate the user's CSR. I then paste in the
contents of the CSR and hit 'Issue' and run into the following error:
==========
IPA Error 907: NetworkError
cannot connect to
'https://REDACTED-1.ipa.REDACTED.com:443/ca/rest/account/login': [SSL:
TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:2508)
==========
As I then start digging into cli-mode to attempt to understand where
things are unhappy, I run into similar troubles with the server
attempting to talk to itself and not being very happy about it.
==========
chris@REDACTED-1:~$ ipa ca-find
------------
1 CA matched
------------
Name: ipa
Description: IPA CA
Authority ID: 8acca54b-64d7-44bf-b8f7-59316213cfb6
Subject DN: CN=Certificate Authority,O=IPA.REDACTED.COM
Issuer DN: CN=Certificate Authority,O=IPA.REDACTED.COM
----------------------------
Number of entries returned 1
----------------------------
chris@REDACTED-1:~$ ipa ca-show
Name: ipa
ipa: ERROR: cannot connect to
'https://REDACTED-1.ipa.REDACTED.com:443/ca/rest/account/login': [SSL:
TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:2508)
==========
Verifying with 'openssl s_client' returns the valid and non-expired LE
cert-chain.
==========
chris@REDACTED-1:~$ openssl s_client REDACTED-1.ipa.REDACTED.com:443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = REDACTED-1.ipa.REDACTED.com
verify return:1
---
Certificate chain
0 s:CN = REDACTED-1.ipa.REDACTED.com
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
...<output-truncated>...
---
SSL handshake has read 3046 bytes and written 413 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
...<output-truncated>...
==========
Can anyone please hit me with some clue-bat as to where I can read to
understand how to get IPA to love itself? I'm suspecting it's likely
some certificate inclusion/exception that I need to add so that API
calls and the ipa command itself will actually respect the LE cert-chain?
Any hints would be greatly appreciated.
Thanks,
-Chris
--
Node-Nine, Inc.
chris(a)node-nine.com
619.354.6463
2 years, 3 months
compat branch not browseable
by Joseph Fry
I am just curious why the cn=compat,dc=mydomain,dc=org container cannot be reached when I bind to dc=mydomain,dc=org, but I can see it if I bind directly to it. Is there any way to expose it?
2 years, 3 months
Get date user was deleted and preserved
by Tania Hagan
Hi,
Is there a way to get the date and time a user was deleted and preserved (ipa user-del --preserve) and if possible by who?
Many Thanks,
Tania
2 years, 3 months
Re: How to blend IPA server 4.1.4 on F21 with server 4.6.8 on C7?
by Bret Wortman
I cleaned up the contents of our ldap manually, re-created the replica file, and got a lot further than we have before but ipa-replica-install still failed as below:
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
[1/30]: configuring certificate server instance
ipaserver.install.dogtaginstance: CRITICAL Failed to configure CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmphvJyRY' returned non-zero exit status 1
ipaserver.install.dogtaginstance: CRITICAL See the installation logs and the following files/directories for more information:
ipaserver.install.dogtaginstance: CRITICAL /var/log/pki/pki-tomcat
[error] RuntimeError: CA configuration failed.
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipapython.admintool: ERROR CA configuration failed.
ipapython.admintool: ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
[root@ipa2c7 ~]# ipa-server-install --uninstall -U
ipapython.admintool: ERROR Unable to read /etc/httpd/conf.d/ipa-pki-proxy.conf
ipapython.admintool: ERROR The ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for more information
[root@ipa2c7 ~]# touch /etc/httpd/conf.d/ipa-pki-proxy.conf
[root@ipa2c7 ~]# ipa-server-install --uninstall -U
Deleting this server will leave your installation without a CRL generation master.
ipapython.admintool: ERROR Aborting uninstall operation.
ipapython.admintool: ERROR The ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for more information
It looks to have failed in such a way that it doesn't know how to back out again, which I haven't seen before. Thoughts? The error in ipa-uninstall.log looks like a generic admintool.py error:
2021-06-07T12:31:38Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-OUR-NET.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f05289fdf80>
2021-06-07T12:31:38Z DEBUG raw: config_show(version=u'2.237')
2021-06-07T12:31:38Z DEBUG config_show(rights=False, all=False, raw=False, version=u'2.237')
2021-06-07T12:31:38Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute
return_value = self.run()
File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 319, in run
return cfgr.run()
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 358, in run
self.validate()
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 368, in validate
for _nothing in self._validator():
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 431, in __runner
exc_handler(exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 455, in _handle_validate_exception
self._handle_exception(exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 450, in _handle_exception
six.reraise(*exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 421, in __runner
step()
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 418, in <lambda>
step = lambda: next(self.__gen)
File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from
six.reraise(*exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from
value = gen.send(prev_value)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 633, in _configure
next(validator)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 431, in __runner
exc_handler(exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 455, in _handle_validate_exception
self._handle_exception(exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 518, in _handle_exception
self.__parent._handle_exception(exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 450, in _handle_exception
six.reraise(*exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 515, in _handle_exception
super(ComponentBase, self)._handle_exception(exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 450, in _handle_exception
six.reraise(*exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 421, in __runner
step()
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 418, in <lambda>
step = lambda: next(self.__gen)
File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from
six.reraise(*exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from
value = gen.send(prev_value)
File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 73, in _uninstall
for unused in self._uninstaller(self.parent):
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/__init__.py", line 594, in main
uninstall_check(self)
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 250, in decorated
func(installer)
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 1030, in uninstall_check
ca.uninstall_check(options)
File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line 127, in uninstall_check
raise ScriptError("Aborting uninstall operation.")
2021-06-07T12:31:38Z DEBUG The ipa-server-install command failed, exception: ScriptError: Aborting uninstall operation.
2021-06-07T12:31:38Z ERROR Aborting uninstall operation.
2021-06-07T12:31:38Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for more information
--
Bret Wortman
bret.wortman(a)damascusgrp.com
On Fri, Jun 4, 2021, at 1:32 PM, Bret Wortman wrote:
> Boom. Looking through the ldifs now. Thanks again, Rob.
>
> --
> Bret Wortman
> bret.wortman(a)damascusgrp.com
>
> On Fri, Jun 4, 2021, at 1:22 PM, Rob Crittenden wrote:
> > Bret Wortman wrote:
> > > What's dsctl? I don't see that anywhere on any of my servers (including the more up-to-date ones). My 389 instance is v1.3.3, if that makes a difference...
> > >
> > >
> >
> > Right, really old release.
> >
> > Try: db2ldif -n userRoot -Z EXAMPLE-TEST -a /path/to/ldif/file
> >
> > To get the CA ldif replace userRoot with ipaca.
> >
> > rob
> >
> >
>
2 years, 3 months
