[Freeipa-users] Re: sssd: disable password cache?

[Harald Dunkel via FreeIPA-users]

On 2024-09-23 11:45:56, Harald Dunkel via FreeIPA-users wrote:

Hi folks,

is there some way to disable sssd's password cache? Everytime
a colleague changes his password, he has problems with our
dovecot server, because it runs into a permission denied, until
some privileged user runs "sss_cache -u name" or "sss_cache -E"
or similar.

AFAIU the password is stored for 5400 seconds. Apparently thats
too long. Caching passwords while sssd is connected to LDAP and
Kerberos might be considered a bad idea, anyway. There is an
undocumented option krb5_store_password_if_offline in sssd.conf.
Maybe there are other undocumented options as well?



PS: I don't want to disable caching credentials completely. Sssd
should recognize *changed* credentials, ie a mismatch between the
local cache and the data on the FreeIPA server.


Regards

Harri
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: sssd: disable password cache?

[Harald Dunkel via FreeIPA-users]

On 2024-09-23 13:15:47, Sumit Bose via FreeIPA-users wrote:


by default SSSD tries to do online authentication as long as SSSD is
online, i.e. can reach the server. This behavior can be changed with the
`cached_auth_timeout` option which allows SSSD to used the stored
password hash for authentication for the time given with the option, see
man sssd.conf for details. Did you, by chance, use this option in
sssd.conf?



No, cached_auth_timeout is not set. I am not sure if it is relevant
here, since the user cannot login using his new password. The
cached_auth_timeout seems to be important *after* login for reauthen-
tication.


Regards

Harri
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] sssd: disable password cache?

[Harald Dunkel via FreeIPA-users]

Hi folks,

is there some way to disable sssd's password cache? Everytime
a colleague changes his password, he has problems with our
dovecot server, because it runs into a permission denied, until
some privileged user runs "sss_cache -u name" or "sss_cache -E"
or similar.

AFAIU the password is stored for 5400 seconds. Apparently thats
too long. Caching passwords while sssd is connected to LDAP and
Kerberos might be considered a bad idea, anyway. There is an
undocumented option krb5_store_password_if_offline in sssd.conf.
Maybe there are other undocumented options as well?


Regards

Harri
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: ipa-client-install (4.9.11) confused about chrony

[Harald Dunkel via FreeIPA-users]

PS:

root@srvl048:~# ipa-client-install --uninstall --no-ntp
Unenrolling client from IPA server
Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to 
/etc/sssd/sssd.conf.deleted
Restoring client configuration files
Unconfiguring the NIS domain.
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
CalledProcessError(Command ['/bin/systemctl', 'stop', 'chrony.service'] 
returned non-zero exit status 5: 'Failed to stop chrony.service: Unit 
chrony.service not loaded.\n')
The ipa-client-install command failed. See /var/log/ipaclient-uninstall.log for 
more information
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: ipa-client-install (4.9.11) confused about chrony

[Harald Dunkel via FreeIPA-users]

On 2024-08-19 09:40:18, Alexander Bokovoy wrote:


You need to say 'ipa-client-install -N' to prevent configuring NTP.
Looks like you didn't do that.



You mean ipa-client install (without --no-ntp) restarts chrony even
if it was instructed in the confirmation dialog to not change the
chrony configuration, and then it is expected to die if chrony isn't
installed?

Maybe it is just me, but I am a little bit confused about this
approach.

Regards
Harri
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] ipa-client-install (4.9.11) confused about chrony

[Harald Dunkel via FreeIPA-users]

Hi folks,

running ipa-client-install in an LXC container I stumbled over this:

root@debian12:~# ipa-client-install
This program will set up IPA client.
Version 4.9.11

WARNING: conflicting time&date synchronization service 'ntp' will be disabled 
in favor of chronyd

Discovery was successful!
Do you want to configure chrony with NTP server or pool address? [no]: no
Client hostname: debian12.vs.example.com
Realm: EXAMPLE.COM
DNS Domain: example.com
IPA Server: ipa1.example.com
BaseDN: dc=example,dc=com

Continue to configure the system with these values? [no]: yes
Synchronizing time
Augeas failed to configure file /etc/chrony/chrony.conf
Using default chrony configuration.
CalledProcessError(Command ['/bin/systemctl', 'restart', 'chrony.service'] 
returned non-zero exit status 5: 'Failed to restart chrony.service: Unit 
chrony.service not found.\n')
The ipa-client-install command failed. See /var/log/ipaclient-install.log for 
more information


This seems weird. First it asks about configuring chrony, which was
denied, and yet it fails due to the chrony configuration.

?

This is the freeipa client package 4.9.11 backported to Debian 12.
There is neither crony nor ntp or systemd-timesyncd installed. The
clock is managed on the host.

It is pretty unfortunate that freeipa tries to "mess around" with
the clock, anyway. Keep it simple. I understand that Kerberos might
run into problems when the clock is out-of-sync, but this is very
well documented, and obviously freeipa cannot take all ntp-clones
into account.


Regards

Harri
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: cannot login on FreeIPA web GUI: Your session has expired. Please log in again.

[Harald Dunkel via FreeIPA-users]

Hi Alex,

On 2024-01-24 10:00:42, Alexander Bokovoy via FreeIPA-users wrote:


KCS https://access.redhat.com/articles/7027037 describes a lot of those
details, so I would recommend reading through it and investigating your
ID range configuration based on those details.

We also have upstream document that outlines ID mapping usage in
FreeIPA: https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html




I finally found the error messages: They are in the LDAP log, in
/var/log/dirsrv/slapd-EXAMPLE-DE/errors. There were a few errors
to fix (a GID 100 outside of the defined idranges, a duplicate
GID, ...), but my FreeIPA seems to be running again.

Thank you very much for your support


Regards

Harri
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: cannot login on FreeIPA web GUI: Your session has expired. Please log in again.

[Harald Dunkel via FreeIPA-users]

Hi Alex,

On 2024-01-24 08:13:44, Alexander Bokovoy wrote:

On Аўт, 23 сту 2024, Harald Dunkel wrote:

I found one problem by now: Regular UIDs start with 501 in my environment,
for historical reasons. The GIDs are >=1000. When we migrated from good ol'
yellow pages to FreeIPA there was no problem with small UIDs. And in the
BSD and SYSV years before Linux only the UIDs <100 were reserved for system.

Do I have to migrate the existing users between 501 and 999 to new UIDs
> 1000? I would like to see an error message showing that this is indeed the
problem, first. Surely I would prefer to just adjust the ID ranges instead
of migrating about 90 user accounts.

What would you suggest?


You can add a new local ID range to cover existing UIDs/GIDs. Make sure
to set base RID and secondary base RID when defining a new ID range.

See https://access.redhat.com/articles/7027037 for details.



ACK. One question, though: Shouldn't the

ipa config-mod --enable-sid --add-sids

I had run set the missing ipantsecurityidentifier entries at least
for the users matching the existing address range from 1000 to 9?
It didn't, AFAICT. It didn't show an error message, either.


Looking at the changes between the previously installed freeipa
packages and the version I have right now I got

# rpm -q --changelog ipa-server
* Fri Dec 01 2023 Julien Rische  - 4.9.12-11
- Generate Kerberos PAC as soon as server installation completed
  Resolves: RHEL-16532

* Thu Nov 16 2023 Julien Rische  - 4.9.12-10
- ipa-kdb: Detect and block Bronze-Bit attacks
  Resolves: RHEL-16532
- Fix for CVE-2023-5455
  Resolves: RHEL-12577

* Wed Oct 04 2023 Julien Rische  - 4.9.12-9
:
:

4.9.12-9 was the previous version. It worked fine. Fixing the CVEs
was the reason for the upgrade. Kerberos authentication is fine in
the new setup, too. How comes these changes triggered the problem
about missing ipantsecurityidentifier entries? Is this as intended?


Regards

Harri
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: cannot login on FreeIPA web GUI: Your session has expired. Please log in again.

[Harald Dunkel via FreeIPA-users]

Hi Alex,

On 2024-01-23 14:41:30, Alexander Bokovoy wrote:

One issue we identified today together with Fedora infrastructure team
is that staged users (created with 'ipa stageuser-add') will prevent
sidgen plugin to generate entries.



I didn't even know this command.

[root@ipa0 ~]# ipa stageuser-find
---
0 users matched
---

Number of entries returned 0




Still trying to find the right documentation.


All documentation was mentioned already in these threads. Please see at
https://access.redhat.com/articles/7027037 for more details (needs RHEL
subscription, including a free developer subscription).



Thank you for the link.

I found one problem by now: Regular UIDs start with 501 in my environment,
for historical reasons. The GIDs are >=1000. When we migrated from good ol'
yellow pages to FreeIPA there was no problem with small UIDs. And in the
BSD and SYSV years before Linux only the UIDs <100 were reserved for system.

Do I have to migrate the existing users between 501 and 999 to new UIDs
>1000? I would like to see an error message showing that this is indeed the
problem, first. Surely I would prefer to just adjust the ID ranges instead
of migrating about 90 user accounts.

What would you suggest?


Regards
Harri
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: cannot login on FreeIPA web GUI: Your session has expired. Please log in again.

[Harald Dunkel via FreeIPA-users]

Hi Soeren,

On 2024-01-23 14:06:11, Sören R. via FreeIPA-users wrote:

Hi Harri,

did you check your admin user, if the attribute is set?

# ipa user-show admin --all | grep ipantsecurityidentifier



The admin user has this attribute set, but my own account used to access
the web interface hasn't. I am still trying to find a way how to add
this ipantsecurityidentifier attribute to all users, but wasn't there
some kind of builtin supposed to fix this automagically?

Still trying to find the right documentation.


Regards

Harri
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] cannot login on FreeIPA web GUI: Your session has expired. Please log in again.

[Harald Dunkel via FreeIPA-users]

Hi folks,

after the upgrade from ipa-server.x86_64 4.9.12-9 to version 4.9.12-11
my FreeIPA servers' web interfaces became inaccessible. At login time there
is a message

Your session has expired. Please log in again.

I found some other threads about similar problems in this ML. However, the
suggested fix to create SIDs

[root@ipa0 log]# /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid 
--netbios-name EXAMPLE --add-sids
Configuring SID generation
  [1/8]: creating samba domain object
Samba domain object already exists
  [2/8]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
  [3/8]: adding RID bases
RID bases already set, nothing to do
  [4/8]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [5/8]: activating sidgen task
Sidgen task plugin already configured, nothing to do
  [6/8]: restarting Directory Server to take MS PAC and LDAP plugins changes 
into account
  [7/8]: adding fallback group
Fallback group already set, nothing to do
  [8/8]: adding SIDs to existing users and groups
This step may take considerable amount of time, please wait..
Done.
The ipa-enable-sid command was successful
[root@ipa0 log]# echo $?
0

did not help. I still cannot login on the web interface. (Looking at the
output it didn't had to do anything, anyway. AFAIR this SID thingy was
already done during migration from CentOS 7 to 8, AFAIR).

[root@ipa0 ~]# ipa idrange-find --raw

3 ranges matched

  cn: EXAMPLE.DE_id_range
  ipabaseid: 37940
  ipaidrangesize: 20
  ipabaserid: 37940
  ipasecondarybaserid: 37960
  iparangetype: ipa-local

  cn: EXAMPLE.DE_posix
  ipabaseid: 1000
  ipaidrangesize: 99000
  ipabaserid: 1000
  ipasecondarybaserid: 10
  iparangetype: ipa-local

  cn: EXAMPLE.DE_subid_range
  ipabaseid: 2147483648
  ipaidrangesize: 2147352576
  ipabaserid: 2147283648
  ipanttrusteddomainsid: S-1-5-21-738065-838566-194929194
  iparangetype: ipa-ad-trust

Number of entries returned 3


/var/log/messages shows

Jan 23 13:50:28 ipa0 [6654]: GSSAPI Error: Unspecified GSS failure.  Minor code 
may provide more information (Credential cache is empty)
Jan 23 13:50:28 ipa0 [6653]: GSSAPI Error: Unspecified GSS failure.  Minor code 
may provide more information (Credential cache is empty)
Jan 23 13:50:31 ipa0 [6654]: GSSAPI Error: Unspecified GSS failure.  Minor code 
may provide more information (Credential cache is empty)
Jan 23 13:50:31 ipa0 [6653]: GSSAPI Error: Unspecified GSS failure.  Minor code 
may provide more information (Credential cache is empty)


/var/log/krb5kdc.log

Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): TGS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: 
S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1706012763, etypes 
{rep=UNSUPPORTED:(0)} HTTP/ipa0.example...@example.de for 
ldap/ipa0.example...@example.de, KDC policy rejects request
Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): ... CONSTRAINED-DELEGATION 
s4u-client=
Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): closing down fd 4
Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): TGS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: 
S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1706012763, etypes 
{rep=UNSUPPORTED:(0)} HTTP/ipa0.example...@example.de for 
ldap/ipa0.example...@example.de, KDC policy rejects request
Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): ... CONSTRAINED-DELEGATION 
s4u-client=
Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): closing down fd 4
Jan 23 13:50:30 ipa0.example.de krb5kdc[6611](info): AS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: 
NEEDED_PREAUTH: WELLKNOWN/anonym...@example.de for 
krbtgt/example...@example.de, Additional pre-authentication required
Jan 23 13:50:30 ipa0.example.de krb5kdc[6611](info): closing down fd 4
Jan 23 13:50:31 ipa0.example.de krb5kdc[6587](info): AS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: ISSUE: 
authtime 1706014231, etypes {rep=aes256-cts-hmac-sha384-192(20), 
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, 
WELLKNOWN/anonym...@example.de for krbtgt/example...@example.de
Jan 23 13:50:31 ipa0.example.de krb5kdc[6587](info): closing down fd 4
Jan 23 13:50:31 ipa0.example.de krb5kdc[6611](info): AS_R

[Freeipa-users] Rocky 8: how to set security-policy to FUTURE without losing FreeIPA?

[Harald Dunkel via FreeIPA-users]

Hi folks,

our security scanner complains about weak ciphers in Rocky 8
(httpd and ssh). security policy is set to "DEFAULT". If I set
it to "FUTURE", then httpd is not started anymore (breaking
ipa.service) due to some short keys. From the httpd error
log:

[Tue Aug 01 07:15:37.847520 2023] [suexec:notice] [pid 13991:tid 
140196092746048] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Aug 01 07:15:37.849785 2023] [ssl:emerg] [pid 13991:tid 140196092746048] 
AH02562: Failed to configure certificate ipaca8.example.com:443:0 (with chain), 
check /var/lib/ipa/certs/httpd.crt
[Tue Aug 01 07:15:37.849826 2023] [ssl:emerg] [pid 13991:tid 140196092746048] 
SSL Library Error: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key 
too small
AH00016: Configuration Failed

The httpd key and cert was generated by FreeIPA just a few
weeks ago, so I wonder how to proceed in this case? Upgrade
to Rocky 9 to get better defaults?


Regards

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] bad list of CAs on FreeIPA client?

[Harald Dunkel via FreeIPA-users]

Hi folks,

getcert list-cas returns on some FreeIPA clients

root@nasl006a:~# getcert list-cas
CA 'SelfSign':
is-default: no
ca-type: INTERNAL:SELF
next-serial-number: 01
CA 'IPA':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/lib/certmonger/ipa-submit
CA 'certmaster':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/lib/certmonger/certmaster-submit
CA 'dogtag-ipa-renew-agent':
is-default: no
ca-type: EXTERNAL
helper-location: 
/usr/lib/certmonger/dogtag-ipa-renew-agent-submit
CA 'local':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/lib/certmonger/local-submit

certmaster-submit doesn't exist, but there are others not included
in this list:

# find /usr/lib/certmonger -name \*-submit
/usr/lib/certmonger/dogtag-ipa-renew-agent-submit
/usr/lib/certmonger/scep-submit
/usr/lib/certmonger/local-submit
/usr/lib/certmonger/ipa-submit
/usr/lib/certmonger/dogtag-submit

Is this something to be worried about? FreeIPA is version 4.9.8-1~bpo11+1
from the Debian backports repository.


Regards

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] ipa-replica-manage dnanextrange-del ?

[Harald Dunkel via FreeIPA-users]

Hi folks,

being tired I have set a dnanextrange on 2 servers, instead of a
dnarange. Very painful. Now our favorite ID range is blocked.

Is there some kind of

ipa-replica-manage dnanextrange-del

to drop a dnanextrange and to return it to the available pool
of IDs?


Every helpful comment is highly appreciated.

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: ipa-csreplica-manage -v list: duplicate replica ID detected

[Harald Dunkel via FreeIPA-users]

Hi Rob,

I highly appreciate your reply. Apparently the problem for cs
went away on its own. "ipa-csreplica-manage -v list" doesn't
show "duplicate replica ID detected" anymore.

But I do have a replication problem for domain. list-ruv shows
on ipa0 and ipa1 (sorted)

Replica Update Vectors:
ipa0.example.com:389: 26
ipa0.example.com:389: 36
ipa1.example.com:389: 38
ipa1.example.com:389: 4
ipa2.example.com:389: 40
ipa3.example.com:389: 42
ipa4.example.com:389: 43
ipa5.example.com:389: 44
ipabak.ac.example.com:389: 45
ipaca8.example.com:389: 34
Certificate Server Replica Update Vectors:
ipa0.example.com:389: 37
ipa1.example.com:389: 39
ipa2.example.com:389: 41
ipabak.ac.example.com:389: 46
ipaca8.example.com:389: 35

Please note the double entries for ipa0 and ipa1. On the other
ipa servers there is no line with ID 26. On all hosts I can
find 2 entries for ipa1 (4 and 38).

AFAIU I have to run ipa-replica-manage clean-ruv for ID 4 and
ID 26 on either ipa0 or ipa1. Is this correct?


Regards

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] ipa-csreplica-manage -v list: duplicate replica ID detected

[Harald Dunkel via FreeIPA-users]

Hi folks,

I have almost completed the FreeIPA migration from CentOS7 to Rocky8 (FreeIPA 
4.9.11).
Domain replications seems to be fine, but I get a replication error for ca:

[root@ipa2 ~]# ipa-csreplica-manage -v list ipaca8.example.com
Directory Manager password:

ipa2.example.com
  last init status: Error (0) Total update succeeded
  last init ended: 2023-07-08 14:35:09+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2023-07-08 16:20:37+00:00
ipabak.ac.example.com
  last init status: Error (0) Total update succeeded
  last init ended: 2023-07-08 16:06:05+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2023-07-08 16:20:37+00:00
ipa0.example.com
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2023-07-08 16:20:37+00:00

[root@ipa2 ~]# ipa-csreplica-manage -v list ipa2.example.com
Directory Manager password:

ipaca8.example.com
  last update status: Error (11) Replication error acquiring replica: Unable to 
acquire replica: the replica has the same Replica ID as this one. Replication 
is aborting. (duplicate replica ID detected)
  last update ended: 2023-07-08 15:03:47+00:00
ipa1.example.com
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2023-07-08 16:20:40+00:00


Obviously replication between ipaca8 (the CA) amd ipa2 is bad. Here is
the topology for ca:

[root@ipa2 ~]# ipa topologysegment-find ca | sed s/aixigo.de/example.com/g

--
5 segments matched
--
  Segment name: ipa0.example.com-to-ipa1.example.com
  Left node: ipa0.example.com
  Right node: ipa1.example.com
  Connectivity: both

  Segment name: ipa0.example.com-to-ipaca8.example.com
  Left node: ipa0.example.com
  Right node: ipaca8.example.com
  Connectivity: both

  Segment name: ipa1.example.com-to-ipa2.example.com
  Left node: ipa1.example.com
  Right node: ipa2.example.com
  Connectivity: both

  Segment name: ipa2.example.com-to-ipaca8.example.com
  Left node: ipa2.example.com
  Right node: ipaca8.example.com
  Connectivity: both

  Segment name: ipabak.ac.example.com-to-ipaca8.example.com
  Left node: ipabak.ac.example.com
  Right node: ipaca8.example.com
  Connectivity: both

Number of entries returned 5



Every helpful hint is highly appreciated
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] migrating CA renewal server to RHEL 8 (using an external root CA)

[Harald Dunkel via FreeIPA-users]

Hi folks,

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/migrating_to_identity_management_on_rhel_8/index#assigning-the-ca-renewal-server-role-to-the-rhel-8-idm-server_migrate-7-to-8

describes how to move the CA renewal server from RHEL 7 to a new
host with RHEL 8, apparently for using a self-signed root CA. Is
this the same procedure for using an external root CA? Do I have
to create a CSR for the new host first, to be signed by the
external CA, and then import it?

Sorry for asking, but I have the impression this detail is missing
in RedHat's documentation. Every insightful comment is highly
appreciated.

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: struggling with RID base on migration from CentOS 7 to 8

[Harald Dunkel via FreeIPA-users]

Hi Sumit,

On 2023-07-03 09:57:53, Sumit Bose via FreeIPA-users wrote:


A proper backup is always recommended when doing such kind of
operations. Adding the RID bases with ldapmodify should for a start
have no additional effects. Only when you start to add new users the
sidgen plugin might now start to add a SID to the new users.

For the existing users you have to start a sidgen task manually. This
might even be required for the migration because recent version of IPA
require a SID for IPA users even if there is no trust to AD.



Would you recommend to run this sidgen task on CentOS 7 using old FreeIPA
4.6.8-5, as a preparation for the migration? I'd love to move all obstacles
out of the way before connecting a newer FreeIPA replica based on Rocky 8.


Regards

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Active Directory domain range with bad ID range

[Harald Dunkel via FreeIPA-users]

Hi folks,

I have found an Active Directory domain range in my FreeIPA setup using -1
as the first Posix ID:

  Range name: EXAMPLE.COM_subid_range
  First Posix ID of the range: 2147483648
  Number of IDs in the range: 2147352576
  First RID of the corresponding RID range: 2147283648
  Domain SID of the trusted domain: S-1-5-21-738065-838566-194929194
  Range type: Active Directory domain range

The GUI shows a warning about this, see https://pagure.io/freeipa/issue/9408.
Is it save to kick out this ID range? AFAICS there are no users or groups
defined using an ID out of this range. And there is not trust relationship to
an AD server.

Every insightful comment is highly appreciated

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: struggling with RID base on migration from CentOS 7 to 8

[Harald Dunkel via FreeIPA-users]

PS: Of course it is Rocky8.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] struggling with RID base on migration from CentOS 7 to 8

[Harald Dunkel via FreeIPA-users]

Hi folks,

still trying to migrate from Centos7 to 8 I get an error message
from ipa-replica-install on the first CentOS 8 host saying

:
Finalize replication settings
Restarting the KDC
Configuring SID generation
  [1/7]: creating samba domain object
Samba domain object already exists
  [2/7]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
  [3/7]: adding RID bases
Found more than one local domain ID range with no RID base set.
  [error] RuntimeError: Too many ID ranges

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Too many ID ranges

The ipa-replica-install command failed. See 
/var/log/ipareplica-install.log for more information

The existing servers running CentOS 7 show a huge set of irritating error
messages in their ipareplica-install.log, e.g.

[01/Jul/2023:14:28:21.640127492 +0200] - ERR - get_ranges - [file 
ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct.
[01/Jul/2023:14:28:21.643664115 +0200] - ERR - ipa_sidgen_add_post_op - [file 
ipa_sidgen.c, line 140]: Failed to get ID ranges.
[01/Jul/2023:14:28:28.521873989 +0200] - ERR - get_ranges - [file 
ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct.
[01/Jul/2023:14:28:28.50535 +0200] - ERR - ipa_sidgen_add_post_op - [file 
ipa_sidgen.c, line 140]: Failed to get ID ranges.
[01/Jul/2023:14:28:28.586507750 +0200] - ERR - NSMMReplicationPlugin - bind_and_check_pwp 
- agmt="cn=meToipaca8.example.com" (ipaca8:389) - Replication bind with GSSAPI 
auth failed: LDAP error 49 (Invalid credentials) ()
[01/Jul/2023:14:28:28.592028265 +0200] - ERR - get_ranges - [file 
ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct.
[01/Jul/2023:14:28:28.596813608 +0200] - ERR - ipa_sidgen_add_post_op - [file 
ipa_sidgen.c, line 140]: Failed to get ID ranges.
[01/Jul/2023:14:28:28.634530928 +0200] - INFO - NSMMReplicationPlugin - 
bind_and_check_pwp - agmt="cn=meToipaca8.example.com" (ipaca8:389): Replication 
bind with GSSAPI auth resumed
[01/Jul/2023:14:28:29.734133911 +0200] - INFO - NSMMReplicationPlugin - repl5_tot_run - Beginning 
total update of replica "agmt="cn=meToipaca8.example.com" (ipaca8:389)".
[01/Jul/2023:14:28:29.879962503 +0200] - ERR - NSMMReplicationPlugin - 
check_flow_control_tot_init - agmt="cn=meToipaca8.example.com" (ipaca8:389) -  
Total update flow control gives time (2000 msec) to the consumer before sending more 
entries [ msgid sent: 1273, rcv: 272])
If total update fails you can try to increase nsds5ReplicaFlowControlPause 
and/or decrease nsds5ReplicaFlowControlWindow in the replica agreement 
configuration
[01/Jul/2023:14:28:37.172991476 +0200] - INFO - NSMMReplicationPlugin - repl5_tot_run - Finished 
total update of replica "agmt="cn=meToipaca8.example.com" (ipaca8:389)". Sent 
2450 entries.
[01/Jul/2023:14:28:37.184680247 +0200] - ERR - NSMMReplicationPlugin - 
agmt="cn=meToipaca8.example.com" (ipaca8:389): Total update flow control 
triggered 2 times
You may increase nsds5ReplicaFlowControlPause and/or decrease 
nsds5ReplicaFlowControlWindow in the replica agreement configuration
[01/Jul/2023:14:28:39.292861041 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - 
agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission 
denied. The bind dn "" does not have permission to supply replication updates to the 
replica. Will retry later.
[01/Jul/2023:14:28:42.238638987 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - 
agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission 
denied. The bind dn "" does not have permission to supply replication updates to the 
replica. Will retry later.
[01/Jul/2023:14:28:45.252557867 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - 
agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission 
denied. The bind dn "" does not have permission to supply replication updates to the 
replica. Will retry later.
[01/Jul/2023:14:28:48.099823076 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - 
agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission 
denied. The bind dn "" does not have permission to supply replication updates to the 
replica. Will retry later.
[01/Jul/2023:14:28:51.115124375 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - 
agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission 
denied. The bind dn "" does not have permission to supply replication updates to the 
replica. Will retry later.
[01/Jul/2023:14:28:54.569369909 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - 
agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission 
denied. The bind dn "" does not have permission t

[Freeipa-users] Re: how to set the RIDs during migration to Rocky 8?

[Harald Dunkel via FreeIPA-users]

On 2023-06-26 10:05:00, Alexander Bokovoy wrote:

I am off to vacation for next three weeks but wanted to highlight that
this is a topic we have been discussing on this list for quite few
months. There is a documentation available that covers some aspects of
it but not everything, surely.

Please see my answers in this thread (dated March 2023) for some of the
reasons:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/HC54UQIEJQVMKZ6S5A5DCAJ4WYYTYJ7E/

and some materials are available in this thread:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/RSAXURG6AR3MWONR3CZSOOI5ULDB2UVC/

and few others.



I am not interested in an AD integration, so please excuse that I
didn't follow this discussion. I will check.


This all affects FreeIPA, Samba AD, MIT Kerberos, and Heimdal, as well
as Microsoft's implementation of Active Directory with or without trust
to other AD. The issues are real, with real exploits in the wild, so we
had to work on tightening things up in multiple projects.



English is not my mother's language, so I am not sure what "tightening
things up" is supposed to mean in this context.


I am yet to complete that promised blog article, may be I'll find time
for that on this vacation...



Get a rest first. Use your vacation days to relax and to have fun. Your
blog won't run away.


Regards

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: how to set the RIDs during migration to Rocky 8?

[Harald Dunkel via FreeIPA-users]

Hi Flo,

On 2023-06-23 14:48:25, Florence Blanc-Renaud via FreeIPA-users wrote:


The 2 above ranges don't have "First RID of the corresponding RID range" and "First 
RID of the secondary RID range" set. If you edit them with ipa idrange-mod --rid-base=INT 
--secondary-rid-base=INT this should fix the issue. The installer is able to add these values if 
there is only one range but prefers to let the admin manually select the right values if there are 
multiple ranges.

For more information you can refer to https://pagure.io/freeipa/issue/9076 
, which contains a link to a mail thread 
with the workaround and a KCS.



AFAIU this RID thing is about AD trust relationship. This is
something I do not have (literally). Is it possible to get rid
of these RIDs and the unwanted 3rd ID range instead?


Regards

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] how to set the RIDs during migration to Rocky 8?

[Harald Dunkel via FreeIPA-users]

Hi folks,

I am trying to migrate FreeIPA from CentOS7 to Rocky 8. No AD trust
relationship involved by now. Problem: ipa-replica-install on the
first Rocky 8 host to join the IPA servers complained


# --
[root@ipaca8 ~]# ipa-replica-install --setup-ca --ip-address 172.19.96.100
Trust is configured but no NetBIOS domain name found, setting it now.
Enter the NetBIOS name for the IPA domain.
Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
Example: EXAMPLE.


NetBIOS domain name [EXAMPLE]:


WARNING: 564 existing users or groups do not have a SID identifier assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin generate
the SID identifier for all these users. Please note, in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1) man page
for details.

Do you want to run the ipa-sidgen task? [no]: yes
Run connection check to master
Connection check OK
Disabled p11-kit-proxy
Configuring directory server (dirsrv). Estimated time: 30 seconds
   [1/39]: creating directory server instance
Validate installation settings ...
Create file system structures ...
selinux is disabled, will not relabel ports or files.
Create database backend: dc=example,dc=de ...
Perform post-installation tasks ...
   [2/39]: tune ldbm plugin
   [3/39]: adding default schema
   [4/39]: enabling memberof plugin
   [5/39]: enabling winsync plugin
   [6/39]: configure password logging
:
:
   [20/30]: starting certificate server instance
   [21/30]: Finalize replication settings
   [22/30]: configure certmonger for renewals
   [23/30]: Importing RA key
   [24/30]: configure certificate renewals
   [25/30]: Configure HTTP to proxy connections
   [26/30]: updating IPA configuration
   [27/30]: enabling CA instance
   [28/30]: importing IPA certificate profiles
Lookup failed: Preferred host ipaca8.example.de does not provide CA.
Lookup failed: Preferred host ipaca8.example.de does not provide CA.
Failed to import profile 'acmeIPAServerCert': Request failed with status 500: 
Non-2xx response from CA REST API: 500. . Running ipa-server-upgrade when 
installation is completed may resolve this issue.
   [29/30]: configuring certmonger renewal for lightweight CAs
   [30/30]: deploying ACME service
Done configuring certificate server (pki-tomcatd).
Configuring Kerberos KDC (krb5kdc)
   [1/1]: installing X509 Certificate for PKINIT
Done configuring Kerberos KDC (krb5kdc).
Applying LDAP updates
Upgrading IPA:. Estimated time: 1 minute 30 seconds
   [1/10]: stopping directory server
   [2/10]: saving configuration
   [3/10]: disabling listeners
   [4/10]: enabling DS global lock
   [5/10]: disabling Schema Compat
   [6/10]: starting directory server
   [7/10]: upgrading server
Could not get dnaHostname entries in 60 seconds
   [8/10]: stopping directory server
   [9/10]: restoring configuration
   [10/10]: starting directory server
Done.
Finalize replication settings
Restarting the KDC
Configuring SID generation
   [1/8]: creating samba domain object
   [2/8]: adding admin(group) SIDs
   [3/8]: adding RID bases
Found more than one local domain ID range with no RID base set.
   [error] RuntimeError: Too many ID ranges

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Too many ID ranges

The ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
more information
# --






Here is the list of id ranges:
# --
[root@ipaca8 ~]# ipa idrange-find --all --raw

3 ranges matched

   dn: cn=EXAMPLE.DE_id_range,cn=ranges,cn=etc,dc=example,dc=de
   cn: EXAMPLE.DE_id_range
   ipabaseid: 37940
   ipaidrangesize: 20
   iparangetype: ipa-local
   objectclass: top
   objectclass: ipaIDrange
   objectclass: ipaDomainIDRange

   dn: cn=EXAMPLE.DE_posix,cn=ranges,cn=etc,dc=example,dc=de
   cn: EXAMPLE.DE_posix
   ipabaseid: 1000
   ipaidrangesize: 99000
   iparangetype: ipa-local
   objectclass: ipadomainidrange
   objectclass: ipaIDrange

   dn: cn=EXAMPLE.DE_subid_range,cn=ranges,cn=etc,dc=example,dc=de
   cn: EXAMPLE.DE_subid_range
   ipabaseid: 2147483648
   ipaidrangesize: 2147352576
   ipabaserid: 2147283648
   ipanttrusteddomainsid: S-1-5-21-738065-838566-194929194
   iparangetype: ipa-ad-trust
   objectclass: top
   objectclass: ipaIDrange
   objectclass: ipaTrustedADDomainRange

Number of entries returned 3

# --



I didn't ask for an AD trust relationship, introducing even more complexity
to something that should be kept as simple as possible. And now its making
problems :-(

[Freeipa-users] Re: road-warrior laptop vs password change in FreeIPA

[Harald Dunkel via FreeIPA-users]

On 2022-07-16 16:03:15, Sam Morris via FreeIPA-users wrote:


The user experience for this is not ideal (it's something my
orgnaization suffers from as well). My two ideas for how to improve it are:

   * A VPN that connects on boot, using the host's identity instead
 of the user (ideally combined with some clever Enterprise networking
 solution that puts the client into a separate network where it can
 do very little other than reach your KDCs until the user has
 authenticated)
   * Make the KDC service accessible to the Internet via ms-kkdcp, which
 is supported by FreeIPA, but I think you have to make some changes
 to kdc.conf on the clients as well



I found a workaround using xscreensaver:

* establish the VPN connection to the office network, including the
  FreeIPA server
* use xscreensaver-demo to lock the screen now
* unlock the screensaver using the new password. This seems to
  update the local cached entry as well.
* use seahorse to change the passphrase of your login keyring
  accordingly


Worked for me.

Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: road-warrior laptop vs password change in FreeIPA

[Harald Dunkel via FreeIPA-users]

As written before, wifi and VPN connections are established *after* the
user logged in using information stored in the cache. I can't help it.
Esp. I cannot support a VPN connection at boot time in a wifi network I
have no information about.

I understand that caching the user information is necessary. My question
is, how to update this cache after the user logged in using the cached
credentials?

There are a lot of security features in FreeIPA: password policies, one-
time-passwords, expiration dates, security tokens, etc. What am I
supposed to tell my colleagues? Whatever you do, never change your pass-
word to avoid confusion?


Regards

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] road-warrior laptop vs password change in FreeIPA

[Harald Dunkel via FreeIPA-users]

Hi folks,

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

kinit username
sss_cache -E
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

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Upgrading from EL7.9 to EL8

[Harald Dunkel via FreeIPA-users]

Hi Alex,

On 2022-06-15 16:23:53, Alexander Bokovoy via FreeIPA-users wrote:


The same as with not doing backports to older OSes, FreeIPA depends on a
*particular set* of integrated services and libraries, not just any. We
choose to avoid some of tough to solve upgrade issues by doing upgrade
by replication. Sometimes battles won by not fighting them.



You mean I cannot upgrade to FreeIPA 4.9.x on RHEL7, either? That was
plan B.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Upgrading from EL7.9 to EL8

[Harald Dunkel via FreeIPA-users]

On 2022-06-15 14:15:12, Rob Crittenden via FreeIPA-users wrote:


Major version upgrades via adding a new machine is the recommended and
documented route. It includes retiring existing, older servers, so have
a plan for that.



How comes? Maybe I am wrong, but I saw FreeIPA as a set of (complex) services
integrated with each other, but without "deep" operating system integration. A
few services talking with each other, so to say. And unlike others FreeIPA 
brings
its own HA.

?


No complaint, of course. I am just curious. Regards

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: freeIPA Status Debian/Ubuntu

[Harald Dunkel via FreeIPA-users]

On 9/5/21 22:24, Nico Maas via FreeIPA-users wrote:

Looks like you're right: https://packages.debian.org/search?keywords=freeipa
Is there any client planned for Bullseye?



AFAICT: No.

Freeipa is in sid (aka "Unstable"). The current version 4.8.10-2 is easy to
backport to Debian 11 and to store in a private repository. I have asked for
a backport on the debian-backports mailing list.

Ubuntu provides freeipa 4.8.6 and some older versions, but I did not try
these.


Regards
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] when will my ca certificate expire?

[Harald Dunkel via FreeIPA-users]

Hi folks,

how can I list the expiration dates of the ca certificate chain, before
it is too late? External ca.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] CentOS 7 --> 8 migration for FreeIPA with external CA?

[Harald Dunkel via FreeIPA-users]

Hi folks,

I have found several migration guidelines from Centos 7 to 8. AFAIU
the procedure is to setup a new CentOS 8 FreeIPA server, and then to
migrate the "master" from the old to the new host. See [1], for example.

Having myself burned with the CA stuff in FreeIPA before, I wonder if
there are any pitfalls wrt having an external root CA and external
DNS? Thats the part not described in [1].

Every helpful comment is highly appreciated
Harri

[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/installing_identity_management/migrate-7-to-8_migrating
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: shouldn't freeipa work by default?

[Harald Dunkel via FreeIPA-users]

On 2020-01-31 10:02, François Cami wrote:


We'd rather fail early and print that warning which lets the admin fix
the issue.
You can see the rationale in the upstream ticket:
https://pagure.io/freeipa/issue/5887


As an admin I won't touch user settings, esp. not the locale variables.
All I can do is to provide the locales.

The point is to make freeipa work by default. It did (up to version 4.4,
AFAIU), and now it doesn't. Of course a user has to expect errors if
he or she actively uses UTF-8 without setting the locales accordingly,
but this is not the case here. And its surely not a problem that freeipa
is supposed to resolve.

The point is to show an error if something in freeipa goes wrong. Pro-
actively printing an error message and exit(1) on *ipa help* gives a
very bad first impression. Shouldn't be too difficult to add some code
like
test -z "$LC_CTYPE$LC_ALL" && export LC_CTYPE=C.UTF-8

to get rid of the problem completely.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] shouldn't freeipa work by default?

[Harald Dunkel via FreeIPA-users]

Hi folks,

*ipa help topics* gives me

# ipa help topics
ipa: ERROR: System encoding must be UTF-8, 'ANSI_X3.4-1968' is not supported. Set LC_ALL="C.UTF-8", 
or LC_ALL="" and LC_CTYPE="C.UTF-8".
# env | egrep LANG\|LC
# echo $?
1

Shouldn't the command line interface work by default? Why not silently
assume UTF-8 and continue?

Printing a warning might be OK.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] how to enable NFS Kerberos authentication?

[Harald Dunkel via FreeIPA-users]

Hi folks,

Maybe I am confused, but apparently I do not have to activate/modify
host-based access control in Freeipa to support Kerberos for NFS. hbac
is not mentioned on 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/kerb-nfs
Is this correct?

Would you recommend setting up weak crypto for NFS? I still have a
few Centos 5 hosts, but they are supposed to be retired in the near
future.

Freeipa is version 4.6.4, running on Centos 7.6.


Every helpful comment is highly appreciated

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Just for the records:

The reason was an updated external root certificate, that I had
imported with bad trust attributes about 2 years ago. My bad.

After fixing the trust attributes freeipa is running again,
probably better than before. There is just a minor issue with
a duplicate csreplica agreement. New thread.

A big thanx to Flo and Rob. They showed helpfulness and competence
in their answers, next to a huge amount of patience.


I highly appreciate your help

Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: setting up a new CA replica in LXC failed

[Harald Dunkel via FreeIPA-users]

Hi Rob,

On 7/17/19 1:55 PM, Rob Crittenden via FreeIPA-users wrote:


Bug in dogtag, https://pagure.io/dogtagpki/issue/3039. Fixed in 10.6.3+
according to git tag.



I applied the patch I found in the dogtag ticket to

/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py

in Centos 7 (pki-server-10.5.9-13). The error message about crypto.fips_enabled
is gone.


Regards
Harri
--- pkihelper.py.orig	2019-03-14 11:33:13.0 +0100
+++ pkihelper.py	2019-07-24 13:21:14.133240467 +0200
@@ -2149,6 +2149,13 @@
 # Always initialize FIPS mode as NOT enabled
 self.mdict['pki_fips_mode_enabled'] = False
 
+# Check if /proc/sys/crypto/fips_enabled exists
+if not os.path.exists("/proc/sys/crypto/fips_enabled"):
+config.pki_log.info(
+log.PKIHELPER_FIPS_MODE_IS_NOT_ENABLED,
+extra=config.PKI_INDENTATION_LEVEL_3)
+return False
+
 # Check to see if FIPS is enabled on this system
 command = ["sysctl", "crypto.fips_enabled", "-bn"]
 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Rob,

On 7/23/19 5:16 PM, Rob Crittenden wrote:


I keep saying to ignore this. It doesn't work because the CA isn't
running because the certs aren't updated.

When certmonger pulls the cert out of the IPA tree it will update the
NSS database and whatever other configuration needs to be updated,
including the CA LDAP database.

You need to go back in time (ensure that ntpd/chrondy is not running),
start IPA so it is fully running and then force certmonger to retrieve
the updated certs.



Freeipa is in production 24/7. The masters are containers without a
local clock. And since java is involved, the faketime library is no
solution, either.

What exactly do you mean by "go back in time"? Beyond the "not before"
date of the new certificate? Turning back the clock doesn't make the
bad certificate go away. Do I have to do this on all masters, the ca
masters or only on the renewal master?

The "force certmonger to retrieve the updated certs" is not clear to
me, either.

I would *highly* appreciate another solution for this. AFAICT the
previous certificate expires in a few days on Aug  1 08:06:59 2019 GMT.

Do I have to expect the same problem in 2 years again, when the new
certificate expires? How can I tell freeipa to generate certificates that
last for 10 years?


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Rob,

On 7/23/19 4:01 PM, Rob Crittenden wrote:


It's a red herring. There is a chicken and egg problem here. The KDC
uses LDAP as its backend and 389-ds needs a ticket. 389-ds starts first,
can't get a ticket and then eventually recovers once the KDC is running.

rob



You mean pki-tomcatd doesn't start because slapd did not recover yet?
It waited for a pretty long time (5 or 10 minutes), so I wonder how
long pki-tomcatd would have to wait? How comes this wasn't an issue
until some certs got renewed?

I would guess this chicken-and-egg problem always existed, but now
somebody shot the rooster.

BTW, it would be nice to have an option in ipactl to restart a single
service, e.g.

ipactl restart pki-tomcatd

Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Flo,

On 7/23/19 12:27 PM, Florence Blanc-Renaud via FreeIPA-users wrote:

Hi,

The subsystemCert cert-pki-ca is also stored in LDAP, in 2 places:
- in the entry uid=pkidbuser,ou=people,o=ipaca (in the userCertificate attribute, which can be 
multivalued and contain the old certs along with the most recent one). The description field must 
store the serial corresponding to the most recent one with the format 
2;;;, for instance description: 2;15;CN=Certificate 
Authority,O=DOMAIN.COM;CN=CA Subsystem,O=DOMAIN.COM


ipa1:
3 certs, the last one is up to date, serial number is correct.

ipa0 and other non-renewal masters:
2 certs, both are out-of-date.


- in the entry cn=subsystemCert 
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,, in the userCertificate 
attribute. There should be only one value, for the most recent cert.


This one is up-to-date, AFAICT.



The uid=pkidbuser entry is present only on the replicas with the CA role, while 
the cn=subsystemCert cert-pki-ca entry is present on all the replicas.

If the cert was properly replicated to the other masters, we can assume that the 
replication went well for the cn=subsystemCert 
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc, entry. I would then check the 
content of uid=pkidbuser,ou=people,o=ipaca on all the replicas (this part of the LDAP tree 
is managed by a different replication agreement, o=ipaca vs ).



AFAIU this indicates that the csreplicas are out of sync. This is what
ipa-csreplica-manage tells me:

[root@ipa1 ~]# ipa-csreplica-manage list -v ipa0.example.de
Directory Manager password:

ipa1.example.de
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (-11) Problem connecting to replica - LDAP error: 
Connect error (connection error)
  last update ended: 1970-01-01 00:00:00+00:00

[root@ipa1 ~]# ipa-csreplica-manage list -v ipa1.example.de
Directory Manager password:

ipa0.example.de
  last init status: Error (-11)  - LDAP error: Connect error
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (-11) Problem connecting to replica - LDAP error: 
Connect error (connection error)
  last update ended: 1970-01-01 00:00:00+00:00
ipa2.example.de
  last init status: Error (-11)  - LDAP error: Connect error
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (-11) Problem connecting to replica - LDAP error: 
Connect error (connection error)
  last update ended: 1970-01-01 00:00:00+00:00
ipa5.example.de
  last init status: Error (-11)  - LDAP error: Connect error
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (-11) Problem connecting to replica - LDAP error: 
Connect error (connection error)
  last update ended: 1970-01-01 00:00:00+00:00


AFAIR we've been here before. How comes that it cannot connect? catch22 ?


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Flo,

On 7/23/19 2:49 PM, Florence Blanc-Renaud wrote:

On 7/23/19 12:27 PM, Harald Dunkel via FreeIPA-users wrote:

PS: Attached is slapd's errors file as well. Please note the
Kerberos errors:

:
[23/Jul/2019:11:42:23.714599643 +0200] - ERR - set_krb5_creds - Could not get 
initial credentials for principal [ldap/ipa0.example...@example.de] in keytab 
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested 
realm)

Hi,
This error means that kerberos server is not running on ipa0 when 389-ds server 
starts. What is the output of ipactl status on ipa0? You can restart the 
services with ipactl start --ignore-service-failures (otherwise failure of a 
single IPA service will stop the whole stack).


[root@ipa0 ~]# ipactl start --ignore-service-failures
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting httpd Service
Starting ipa-custodia Service
Starting ntpd Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Forced start, ignoring pki-tomcatd Service, continuing normal operation
Starting ipa-otpd Service
ipa: INFO: The ipactl command was successful

[root@ipa0 ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
ntpd Service: STOPPED
pki-tomcatd Service: STOPPED
ipa-otpd Service: RUNNING
ipa: INFO: The ipactl command was successful

The kdc is running. Its serving requests all the time.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

PS: Attached is slapd's errors file as well. Please note the
Kerberos errors:

:
[23/Jul/2019:11:42:23.714599643 +0200] - ERR - set_krb5_creds - Could not get 
initial credentials for principal [ldap/ipa0.example...@example.de] in keytab 
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested 
realm)
[23/Jul/2019:11:42:23.746685708 +0200] - ERR - schema-compat-plugin - 
schema-compat-plugin tree scan will start in about 5 seconds!
[23/Jul/2019:11:42:23.750736864 +0200] - ERR - slapi_ldap_bind - Error: could 
not send startTLS request: error -11 (Connect error)
[23/Jul/2019:11:42:23.766240272 +0200] - ERR - NSMMReplicationPlugin - bind_and_check_pwp 
- agmt="cn=masterAgreement1-ipa1.example.de-pki-tomcat" (ipa1:389) - 
Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) 
(error:14090086:SSL routines:ssl3_get_server_certifica
:

Regards
Harri


errors.txt.gz
Description: application/gzip
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Rob,

On 7/22/19 5:34 PM, Rob Crittenden via FreeIPA-users wrote:

It is expected. dogtag uses cert auth to bind to LDAP. That fails with
the expired certs. This is why the IPA tree is used to distribute the
updated certificates.

rob


Good news:

Apparently the new certificate did make it into the local cert database.
On the renewal master:

[root@ipa1 ~]# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' | 
grep "Not After"
Not After : Wed Jun 23 09:56:18 2021

On the non-renewal masters, e.g. ipa0:

[root@ipa0 ~]# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' | 
grep "Not After"
Not After : Wed Jun 23 09:56:18 2021


Bad news:

pki-tomcatd still doesn't start on the non-renewal masters. journal
is attached. Is there yet another copy of the certificate (or its ca
chain) that might be out-of-date?

I haven't dared to restart ipa1 yet.


Regards
Harri


journal.txt.gz
Description: application/gzip
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Rob,

On 7/19/19 7:25 PM, Rob Crittenden wrote:


The log doesn't seem to say which cert isn't found. You could try again
and see what is being logged to find out what cert can't be found, and
potentially why.



This might be interesting. An ipactl restart gave me this in /var/log/messages:

Jul 22 16:58:25 ipa0 pkidaemon: --
Jul 22 16:58:25 ipa0 pkidaemon: Enabled all subsystems
Jul 22 16:58:25 ipa0 pkidaemon: --
Jul 22 16:58:25 ipa0 systemd: Started PKI Tomcat Server pki-tomcat.
Jul 22 16:58:25 ipa0 systemd: Reached target PKI Tomcat Server.
Jul 22 16:58:25 ipa0 server: Java virtual machine used: 
/usr/lib/jvm/jre-1.8.0-openjdk/bin/java
Jul 22 16:58:25 ipa0 server: classpath used: 
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
Jul 22 16:58:25 ipa0 server: main class used: 
org.apache.catalina.startup.Bootstrap
Jul 22 16:58:25 ipa0 server: flags used: 
-DRESTEASY_LIB=/usr/share/java/resteasy-base 
-Djava.library.path=/usr/lib64/nuxwdog-jni
Jul 22 16:58:25 ipa0 server: options used: 
-Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat 
-Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp 
-Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.security.manager 
-Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy
Jul 22 16:58:25 ipa0 server: arguments used: start
Jul 22 16:58:26 ipa0 server: WARNING: Problem with JAR file 
[/usr/share/pki/server/common/lib/symkey.jar], exists: [false], canRead: [false]
Jul 22 16:58:27 ipa0 ns-slapd: [22/Jul/2019:16:58:27.296160288 +0200] - ERR - 
slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect 
error)
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'enableOCSP' 
to 'false' did not find a matching property.
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspResponderURL' to 'http://ipa0.example.de:8080/ca/ocsp' did not find a 
matching property.
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a 
matching property.
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspCacheSize' to '1000' did not find a matching property.
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspMinCacheEntryDuration' to '60' did not find a matching property.
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspMaxCacheEntryDuration' to '120' did not find a matching property.
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspTimeout' 
to '10' did not find a matching property.
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'strictCiphers' to 'true' did not find a matching property.
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'sslOptions' 
to 'ssl2=false,ssl3=false,tls=true' did not find a matching property.
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ssl2Ciphers' 
to 
'-SSL2_RC4_128_WITH_MD5,-SSL2_RC4_128_EXPORT40_WITH_MD5,-SSL2_RC2_128_CBC_WITH_MD5,-SSL2_RC2_128_CBC_EXPORT40_WITH_MD5,-SSL2_DES_64_CBC_WITH_MD5,-SSL2_DES_192_EDE3_CBC_WITH_MD5'
 did not find a matching property.
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ssl3Ciphers' 
to 
'-SSL3_FORTEZZA_DMS_WITH_NULL_SHA,-SSL3_FORTEZZA_DMS_WITH_RC4_128_SHA,+SSL3_RSA_WITH_RC4_128_SHA,-SSL3_RSA_EXPORT_WITH_RC4_40_MD5,+SSL3_RSA_WITH_3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_DES_CBC_SHA,-SSL3_RSA_EXPORT_WITH_RC2_CBC_40_MD5,-SSL3_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA,-SSL_RSA_FIPS_WITH_DES_CBC_SHA,+SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_NULL_MD5,-TLS_RSA_EXPORT1024_WITH_RC4_56_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA'
 did not find a matching property.
Jul 22 16:58:27 ipa0 server: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'tlsCiphers' 
to 
'-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,+TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Rob,

On 7/19/19 3:45 PM, Rob Crittenden wrote:

Harald Dunkel via FreeIPA-users wrote:


AFAICS the new certificates are in ldap on the non-renewal masters (e.g.
ipa0). Here is the output of the suggested getcert session on ipa0:

[root@ipa0 ~]# date
Fri Jul 19 11:21:00 CEST 2019
[root@ipa0 ~]# getcert resubmit -d /etc/pki/pki-tomcat/alias/ -n
'subsystemCert cert-pki-ca'
Resubmitting "20181031072253" to "dogtag-ipa-ca-renew-agent".
[root@ipa0 ~]# journalctl -xe
Jul 19 11:20:54 ipa0.example.de server[2612]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1520)

...

Jul 19 11:21:14 ipa0.example.de dogtag-ipa-ca-renew-agent-submit[32209]:
Updated certificate not available

...

This is the important bit. The updated certificate is not in
cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. This is why I asked if IPA
replication was working (not the CA replication). I'd start by looking
at this subtree on all masters to see what, if anything, is in it.



I haven't found a ldapsearch command to show me the certificate as a
pem file yet, but according to jxplorer ipa1 and ipa0 have the same
certificates in cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. Same "Thumprints".
I double checked esp. the CA Subsystem certificate.

The ldap database is in sync, wrt. the certificates in 
cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX

ipa-replica-manage doesn't indicate any problems, either.

On ipa0:

[root@ipa0 ~]# ipa-replica-manage list -v ipa0.example.de
Directory Manager password:

ipa1.example.de: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:27:00+00:00

[root@ipa0 ~]# ipa-replica-manage list -v ipa1.example.de
Directory Manager password:

ipa0.example.de: replica
  last init status: Error (0) Total update succeeded
  last init ended: 2019-07-17 10:06:24+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:28:42+00:00
ipa2.example.de: replica
  last init status: Error (0) Total update succeeded
  last init ended: 2019-07-17 09:54:57+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:28:42+00:00
ipa3.example.de: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:28:42+00:00
ipa4.example.de: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:28:42+00:00
ipa5.example.de: replica
  last init status: Error (0) Total update succeeded
  last init ended: 2019-07-17 10:55:45+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:28:42+00:00


On ipa1:

[root@ipa1 ~]# ipa-replica-manage list -v ipa0.example.de
Directory Manager password:

ipa1.example.de: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:31:07+00:00

[root@ipa1 ~]# ipa-replica-manage list -v ipa1.example.de
Directory Manager password:

ipa0.example.de: replica
  last init status: Error (0) Total update succeeded
  last init ended: 2019-07-17 10:06:24+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:31:26+00:00
ipa2.example.de: replica
  last init status: Error (0) Total update succeeded
  last init ended: 2019-07-17 09:54:57+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:31:26+00:00
ipa3.example.de: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:31:26+00:00
ipa4.example.de: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:31:26+00:00
ipa5.example.de: replica
  last init status: Error (0) Total update succeeded
  last init ended: 2019-07-17 10:55:45+00:00
  last update status: Error (0) Replica acquired successfully: Incremental 
update succeeded
  last update ended: 2019-07-19 15:31:26+00:00


New users are replicated to all ipa servers as well. AFAICS ldap
is in sync.

Would you suggest to do a re-initialize 

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Rob,

On 7/18/19 3:06 PM, Rob Crittenden wrote:

Look in cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com to see if the
updated certificates are there. If they are then try to manually
resubmit the certmonger tracking for it.

For example, for the subsystem cert you'd do something like:

# getcert resubmit -d/etc/pki/pki-tomcat/alias/  -n 'subsystemCert
cert-pki-ca'

This should cause it to pull the updated cert from LDAP and apply it
locally.

Logging will go to the journal.

rob


AFAICS the new certificates are in ldap on the non-renewal masters (e.g.
ipa0). Here is the output of the suggested getcert session on ipa0:

[root@ipa0 ~]# date
Fri Jul 19 11:21:00 CEST 2019
[root@ipa0 ~]# getcert resubmit -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert 
cert-pki-ca'
Resubmitting "20181031072253" to "dogtag-ipa-ca-renew-agent".
[root@ipa0 ~]# journalctl -xe
Jul 19 11:20:54 ipa0.example.de server[2612]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1520)
Jul 19 11:20:54 ipa0.example.de server[2612]: at 
java.lang.Thread.run(Thread.java:748)
Jul 19 11:20:55 ipa0.example.de ns-slapd[2311]: [19/Jul/2019:11:20:55.391823929 
+0200] - ERR - slapi_ldap_bind - Error: could not send startTLS request: error 
-11 (Connect error)
Jul 19 11:20:58 ipa0.example.de ns-slapd[2311]: [19/Jul/2019:11:20:58.417440591 
+0200] - ERR - slapi_ldap_bind - Error: could not send startTLS request: error 
-11 (Connect error)
Jul 19 11:21:01 ipa0.example.de ns-slapd[2311]: [19/Jul/2019:11:21:01.443980720 
+0200] - ERR - slapi_ldap_bind - Error: could not send startTLS request: error 
-11 (Connect error)
Jul 19 11:21:04 ipa0.example.de ns-slapd[2311]: [19/Jul/2019:11:21:04.509715298 
+0200] - ERR - slapi_ldap_bind - Error: could not send startTLS request: error 
-11 (Connect error)
Jul 19 11:21:04 ipa0.example.de server[2612]: WARNING: Exception processing 
realm com.netscape.cms.tomcat.ProxyRealm@775db907 background process
Jul 19 11:21:04 ipa0.example.de server[2612]: 
javax.ws.rs.ServiceUnavailableException: Subsystem unavailable
Jul 19 11:21:04 ipa0.example.de server[2612]: at 
com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137)
Jul 19 11:21:04 ipa0.example.de server[2612]: at 
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1356)
Jul 19 11:21:04 ipa0.example.de server[2612]: at 
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5958)
Jul 19 11:21:04 ipa0.example.de server[2612]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1542)
Jul 19 11:21:04 ipa0.example.de server[2612]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552)
Jul 19 11:21:04 ipa0.example.de server[2612]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552)
Jul 19 11:21:04 ipa0.example.de server[2612]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1520)
Jul 19 11:21:04 ipa0.example.de server[2612]: at 
java.lang.Thread.run(Thread.java:748)
Jul 19 11:21:07 ipa0.example.de ns-slapd[2311]: [19/Jul/2019:11:21:07.532994710 
+0200] - ERR - slapi_ldap_bind - Error: could not send startTLS request: error 
-11 (Connect error)
Jul 19 11:21:10 ipa0.example.de ns-slapd[2311]: [19/Jul/2019:11:21:10.557979236 
+0200] - ERR - slapi_ldap_bind - Error: could not send startTLS request: error 
-11 (Connect error)
Jul 19 11:21:13 ipa0.example.de ns-slapd[2311]: [19/Jul/2019:11:21:13.580909790 
+0200] - ERR - slapi_ldap_bind - Error: could not send startTLS request: error 
-11 (Connect error)
Jul 19 11:21:14 ipa0.example.de dogtag-ipa-ca-renew-agent-submit[32209]: 
Updated certificate not available
Jul 19 11:21:14 ipa0.example.de server[2612]: WARNING: Exception processing 
realm com.netscape.cms.tomcat.ProxyRealm@775db907 background process
Jul 19 11:21:14 ipa0.example.de server[2612]: 
javax.ws.rs.ServiceUnavailableException: Subsystem unavailable
Jul 19 11:21:14 ipa0.example.de server[2612]: at 
com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137)
Jul 19 11:21:14 ipa0.example.de server[2612]: at 
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1356)
Jul 19 11:21:14 ipa0.example.de server[2612]: at 
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5958)
Jul 19 11:21:14 ipa0.example.de server[2612]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1542)
Jul 19 11:21:14 ipa0.example.de server[2612]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552)
Jul 19 11:21:14 ipa0.example.de server[2612]: at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552)
Jul 19 11:21:14 ipa0.example.de serve

[Freeipa-users] Re: freeipa-server failied to install - Debian9

[Harald Dunkel via FreeIPA-users]

Please ignore, I got confused with another thread.
Harri

On 7/19/19 10:22 AM, Harald Dunkel wrote:

Hi Timo,

On 7/19/19 8:51 AM, Timo Aaltonen via FreeIPA-users wrote:

Hi,

Sorry, only Debian unstable is somewhat supported right now, though the
freeipa part is still lacking because of ipa-server-upgrade crashes I'm
seeing which is blocking the upload of current version being staged.
I'll probably rebase to 4.8.0 starting next month and move it all to
python3 now that the Samba packages support it...



don't worry, this thread is about freeipa-server on CentOS 7 in a LXC
container. Debian is the host.

My Debian clients work very well using your freeipa-client package.


Regards
Harri


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: freeipa-server failied to install - Debian9

[Harald Dunkel via FreeIPA-users]

Hi Timo,

On 7/19/19 8:51 AM, Timo Aaltonen via FreeIPA-users wrote:

Hi,

Sorry, only Debian unstable is somewhat supported right now, though the
freeipa part is still lacking because of ipa-server-upgrade crashes I'm
seeing which is blocking the upload of current version being staged.
I'll probably rebase to 4.8.0 starting next month and move it all to
python3 now that the Samba packages support it...



don't worry, this thread is about freeipa-server on CentOS 7 in a LXC
container. Debian is the host.

My Debian clients work very well using your freeipa-client package.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

PS: Below you can find an excerpt from the slapd errors file on ipa1
(the renewal master).

Regards
Harri
[15/Jul/2019:11:31:53.160959903 +0200] - ERR - slapi_ldap_bind - Error: could 
not send startTLS request: error -11 (Connect error)
[15/Jul/2019:11:36:53.653395671 +0200] - ERR - slapi_ldap_bind - Error: could 
not send startTLS request: error -11 (Connect error)
[15/Jul/2019:11:41:53.058845426 +0200] - ERR - slapi_ldap_bind - Error: could 
not send startTLS request: error -11 (Connect error)
[15/Jul/2019:11:46:53.151024629 +0200] - ERR - slapi_ldap_bind - Error: could 
not send startTLS request: error -11 (Connect error)
[15/Jul/2019:11:51:04.583330896 +0200] - WARN - NSMMReplicationPlugin - 
acquire_replica - agmt="cn=meToipa2.example.de" (ipa2:389): Unable to receive 
the response for a startReplication extended operation to co
nsumer (Can't contact LDAP server). Will retry later.
[15/Jul/2019:11:51:10.571064133 +0200] - INFO - NSMMReplicationPlugin - 
bind_and_check_pwp - agmt="cn=meToipa2.example.de" (ipa2:389): Replication bind 
with GSSAPI auth resumed
[15/Jul/2019:11:51:53.061195487 +0200] - ERR - slapi_ldap_bind - Error: could 
not send startTLS request: error -11 (Connect error)
[15/Jul/2019:11:55:18.051457277 +0200] - INFO - op_thread_cleanup - slapd 
shutting down - signaling operation threads - op stack size 19 max work q size 
7 max work q stack size 7
[15/Jul/2019:11:55:18.064908548 +0200] - INFO - slapd_daemon - slapd shutting 
down - waiting for 19 threads to terminate
[15/Jul/2019:11:55:18.078770335 +0200] - INFO - slapd_daemon - slapd shutting 
down - closing down internal subsystems and plugins
[15/Jul/2019:11:55:18.082254490 +0200] - WARN - NSMMReplicationPlugin - 
acquire_replica - agmt="cn=meToipabak.ac.example.de" (ipabak:389): Unable to 
receive the response for a startReplication extended operatio
n to consumer (Timed out). Will retry later.
[15/Jul/2019:11:55:18.090549719 +0200] - WARN - NSMMReplicationPlugin - 
acquire_replica - agmt="cn=meToipa4.example.de" (ipa4:389): Unable to receive 
the response for a startReplication extended operation to co
nsumer (Timed out). Will retry later.
[15/Jul/2019:11:55:18.104784402 +0200] - WARN - NSMMReplicationPlugin - 
acquire_replica - agmt="cn=meToipa2.example.de" (ipa2:389): Unable to receive 
the response for a startReplication extended operation to co
nsumer (Timed out). Will retry later.
[15/Jul/2019:11:55:18.107970198 +0200] - WARN - NSMMReplicationPlugin - 
acquire_replica - agmt="cn=meToipa3.example.de" (ipa3:389): Unable to receive 
the response for a startReplication extended operation to co
nsumer (Timed out). Will retry later.
[15/Jul/2019:11:55:18.789739228 +0200] - ERR - nis-plugin - error sending 
request to portmap or rpcbind on 6: Broken pipe
[15/Jul/2019:11:55:18.794509661 +0200] - ERR - nis-plugin - retried sending 
request to portmap or rpcbind on 11, and succeeded
[15/Jul/2019:11:55:18.801335996 +0200] - ERR - nis-plugin - portmap request 
failed
[15/Jul/2019:11:55:18.809544948 +0200] - ERR - nis-plugin - portmap request 
failed
[15/Jul/2019:11:55:18.818395173 +0200] - ERR - nis-plugin - portmap request 
failed
[15/Jul/2019:11:55:18.826133514 +0200] - ERR - nis-plugin - portmap request 
failed
[15/Jul/2019:11:55:18.844088004 +0200] - ERR - nis-plugin - portmap request 
failed
[15/Jul/2019:11:55:18.847534816 +0200] - ERR - nis-plugin - portmap request 
failed
[15/Jul/2019:11:55:18.857519024 +0200] - INFO - dblayer_pre_close - Waiting for 
4 database threads to stop
[15/Jul/2019:11:55:19.311770607 +0200] - INFO - dblayer_pre_close - All 
database threads now stopped
[15/Jul/2019:11:55:19.406955185 +0200] - INFO - 
ldbm_back_instance_set_destructor - Set of instances destroyed
[15/Jul/2019:11:55:19.411535412 +0200] - INFO - 
connection_post_shutdown_cleanup - slapd shutting down - freed 7 work q stack 
objects - freed 21 op stack objects
[15/Jul/2019:11:55:19.418371030 +0200] - INFO - main - slapd stopped.
[15/Jul/2019:11:55:19.926760501 +0200] - INFO - slapd_extract_cert - CA CERT 
NAME: CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE
[15/Jul/2019:11:55:19.951893692 +0200] - INFO - slapd_extract_cert - CA CERT 
NAME: EXAMPLE.DE IPA CA
[15/Jul/2019:11:55:19.955564732 +0200] - INFO - slapd_extract_cert - CA CERT 
NAME: EXAMPLE.DE IPA CA
[15/Jul/2019:11:55:19.964110018 +0200] - WARN - Security Initialization - SSL 
alert: Sending pin request to SVRCore. You may need to run 
systemd-tty-ask-password-agent to provide the password.
[15/Jul/2019:11:55:19.977359029 +0200] - INFO - slapd_extract_cert - SERVER 
CERT NAME: Server-Cert
[15/Jul/2019:11:55:19.985393892 +0200] - INFO - Security Initialization - SSL 
info: Enabling default cipher set.
[15/Jul/2019:11:55:19.994523569 +0200] - INFO - Security Initialization - SSL 
info: Configured NSS Ciphers
[15/Jul/2019:11:55:20.002138699 +0200] - INFO - Security Initialization - SSL 
info: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
[15/Jul/2019:11:5

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Rob,

On 7/17/19 9:27 PM, Rob Crittenden via FreeIPA-users wrote:


The renewal certificates are passed via the main IPA backend. Check to
see if that replication is working.



It is not:

[root@ipa1 ~]# ipa-csreplica-manage list -v ipa0.example.de
Directory Manager password:

ipa1.example.de
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (-11) Problem connecting to replica - LDAP error: 
Connect error (connection error)
  last update ended: 1970-01-01 00:00:00+00:00

The others show connection errors as well. ipa-replica-manage (without
"cs") doesn't mention any connection problems.


Is it possible that these connection errors occur *because* the
new certificate is not installed yet, and because the old certificate
is not trusted anymore?

Please note also that pki-tomcatd refuses to start on any host except
for ipa1. Error message: Authentication error. See below for the debug
log. Might be unrelated.


Regards
Harri
[16/Jul/2019:09:43:29][localhost-startStop-1]: CMSEngine.shutdown()
[16/Jul/2019:09:49:37][localhost-startStop-1]: 

[16/Jul/2019:09:49:37][localhost-startStop-1]: =  DEBUG SUBSYSTEM 
INITIALIZED   ===
[16/Jul/2019:09:49:37][localhost-startStop-1]: 

[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: restart at 
autoShutdown? false
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: autoShutdown crumb 
file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: about to look for 
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: found 
cert:auditSigningCert cert-pki-ca
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: done init id=debug
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: initialized debug
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: initSubsystem id=log
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: ready to init id=log
[16/Jul/2019:09:49:37][localhost-startStop-1]: Event filters:
[16/Jul/2019:09:49:37][localhost-startStop-1]: Creating 
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit)
[16/Jul/2019:09:49:37][localhost-startStop-1]: Event filters:
[16/Jul/2019:09:49:37][localhost-startStop-1]: Creating 
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system)
[16/Jul/2019:09:49:37][localhost-startStop-1]: Event filters:
[16/Jul/2019:09:49:37][localhost-startStop-1]: Creating 
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions)
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: restart at 
autoShutdown? false
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: autoShutdown crumb 
file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: about to look for 
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: found 
cert:auditSigningCert cert-pki-ca
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: done init id=log
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: initialized log
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: initSubsystem id=jss
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: ready to init id=jss
[16/Jul/2019:09:49:37][localhost-startStop-1]: JssSubsystem: initializing JSS 
subsystem
[16/Jul/2019:09:49:37][localhost-startStop-1]: JssSubsystem: enabled: true
[16/Jul/2019:09:49:37][localhost-startStop-1]: JssSubsystem: NSS database: 
/var/lib/pki/pki-tomcat/alias/
[16/Jul/2019:09:49:37][localhost-startStop-1]: JssSubsystem: initializing 
CryptoManager
[16/Jul/2019:09:49:37][localhost-startStop-1]: JssSubsystem: initializing SSL
[16/Jul/2019:09:49:37][localhost-startStop-1]: JssSubsystem: random:
[16/Jul/2019:09:49:37][localhost-startStop-1]: JssSubsystem: - algorithm: 
pkcs11prng
[16/Jul/2019:09:49:37][localhost-startStop-1]: JssSubsystem: - provider: 
Mozilla-JSS
[16/Jul/2019:09:49:37][localhost-startStop-1]: JssSubsystem: initialization 
complete
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: restart at 
autoShutdown? false
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: autoShutdown crumb 
file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: about to look for 
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: found 
cert:auditSigningCert cert-pki-ca
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: done init id=jss
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: initialized jss
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: initSubsystem id=dbs
[16/Jul/2019:09:49:37][localhost-startStop-1]: CMSEngine: ready to init id=dbs
[16/Jul/2019:09:49:37][localhost-startSto

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Flo,

FYI: ipa2 is essential in our environment, so I reinstalled
the replica (without ca). There are still 2 other hosts
ipa0 and ipabak with the same problem.

On 7/17/19 2:50 PM, Florence Blanc-Renaud wrote:

Hi,
the renewal behaves differently on the renewal master and on other nodes. On 
the renewal master, post-save will upload the new cert to the LDAP entry, and 
replication will propagate this changes to the other masters.


AFAICS this new entry was not replicated.


On a non-renewal master, the renewal obtains the cert from the local LDAP, but 
does not write to LDAP (as the replication is supposed to have executed this 
part).



This part did not work. Since ipa2, ipa0 and the other don't have the
new CA Subsystem certificate yet, I wonder if ipa1 (the renewal master)
still accepts the old certificate for setting up a connection to ipa0?


I don't understand in your case how the getcert resubmit managed to update the 
cert (because it's supposed to get it from the local LDAP server), and 
according to the ldapsearch you did it's not present. Can you double check the 
ldap search but with -h ipa2 -p 389 to make sure the expected server is used?



See below. There is only one conclusion: getcert resubmit did *not* use the
local ldap server.


ldapsearch on ipa0 shows that the replicas are out of sync wrt
certificate information:

[root@ipa0 ~]# ldapsearch -h ipa0 -p 389 -D cn=directory\ manager -W -b o=ipaca 
uid=pkidbuser userCertificate
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: uid=pkidbuser
# requesting: userCertificate
#

# pkidbuser, people, ipaca
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate:: MIIDhjCCAm6gAwIBAgIBAzANBgkqhkiG9w0BAQsFADBBMQswCQYDVQQGEwJE
 :
 DLmWOwnnZiyUGBpv1bM46fBcTuDwHG7NVveaiQ0R1Cpva185zzkyyqDB8AL8ygb/e+8iaY
userCertificate:: MIIDhTCCAm2gAwIBAgIBUzANBgkqhkiG9w0BAQsFADBBMQswCQYDVQQGEwJE
 :
 8DJ0nHC1E4pArqQ/yWDksCpcEWP/woYiF5HgK3jAc5Ba2smS+NyQicpg+ZkpvMPE9ZWsQ=

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@ipa0 ~]# ldapsearch -h ipa1 -p 389 -D cn=directory\ manager -W -b o=ipaca 
uid=pkidbuser userCertificate
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: uid=pkidbuser
# requesting: userCertificate
#

# pkidbuser, people, ipaca
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate:: MIIDhjCCAm6gAwIBAgIBAzANBgkqhkiG9w0BAQsFADBBMQswCQYDVQQGEwJE
 :
 DLmWOwnnZiyUGBpv1bM46fBcTuDwHG7NVveaiQ0R1Cpva185zzkyyqDB8AL8ygb/e+8iaY
userCertificate:: MIIDhTCCAm2gAwIBAgIBUzANBgkqhkiG9w0BAQsFADBBMQswCQYDVQQGEwJE
 :
 8DJ0nHC1E4pArqQ/yWDksCpcEWP/woYiF5HgK3jAc5Ba2smS+NyQicpg+ZkpvMPE9ZWsQ=
userCertificate:: MIIDhTCCAm2gAwIBAgIBaTANBgkqhkiG9w0BAQsFADBBMQswCQYDVQQGEwJE
 :
 qISlV77vwnVQ4f9mHYMDH2fxVn+Yg1NeW7Hfs30w9dh0p1t45KmI5pzEtreyqF/ARtq94=

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


As you can see, ipa1 has a 3rd certificate.




Also, is there a /etc/ipa/renew.conf file with a ldap_uri different from the 
one in /etc/ipa/default.conf on ipa1?



[root@ipa1 ~]# cat /etc/ipa/renew.conf
cat: /etc/ipa/renew.conf: No such file or directory

Same on ipa0.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] setting up a new CA replica in LXC failed

[Harald Dunkel via FreeIPA-users]

Hi folks,

installing a new ca replica in an LXC container failed with

[root@ipa5 ~]# ipa-replica-install --no-ntp --setup-ca 
/var/lib/ipa/replica-info-ipa5.example.de.gpg
Directory Manager (existing master) password:

Run connection check to master
ad...@example.de password:
Connection check OK
Configuring directory server (dirsrv). Estimated time: 30 seconds
  [1/41]: creating directory server instance
  [2/41]: enabling ldapi
  [3/41]: configure autobind for root
:
:
Installation failed:
com.netscape.certsrv.base.PKIException: Error in populating database: 
java.io.IOException: Failed to setup the replication for cloning.

Please check the CA logs in /var/log/pki/pki-tomcat/ca.

2019-07-17T10:57:43Z DEBUG stderr=pkispawn: ERROR... 
subprocess.CalledProcessError:  Command '['sysctl', 'crypto.fips_enabled', 
'-bn']' returned non-zero exit status 255!

2019-07-17T10:57:43Z CRITICAL Failed to configure CA instance: Command 
'/usr/sbin/pkispawn -s CA -f /tmp/tmpZihcFT' returned non-zero exit status 1
2019-07-17T10:57:43Z CRITICAL See the installation logs and the following 
files/directories for more information:
2019-07-17T10:57:43Z CRITICAL   /var/log/pki/pki-tomcat
2019-07-17T10:57:43Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
570, in start_creation
run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
560, in run_step
method()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 
660, in __spawn_instance
pki_pin)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", 
line 166, in spawn_instance
self.handle_setup_error(e)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", 
line 406, in handle_setup_error
raise RuntimeError("%s configuration failed." % self.subsystem)


[root@ipa5 pki-tomcat]# sysctl crypto.fips_enabled -bn
sysctl: cannot stat /proc/sys/crypto/fips_enabled: No such file or directory

sysctl returns the same error on the host.

This crypto.fips_enabled appears to be something optional, so I wonder if
I could tell ipa-replica-install in advance?


The host is running Debian 9.9 and kernel 4.9.168-1+deb9u2.
The client is CentOS 7, ipa 4.6.4-10


Every helpful comment is highly appreciated
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

On 7/16/19 2:39 PM, Harald Dunkel via FreeIPA-users wrote:


ldapsearch -D cn=directory\ manager -W -b o=ipaca uid=pkidbuser userCertificate

does not show the new certificate yet. I thought that the post-save command
for this certificate is supposed to add it to ldap as well. Should I have used
the ipa-getcert command instead?



PS: Of course I tried to resync, but it didn't work:

[root@ipa2 ~]# ipa-csreplica-manage re-initialize --from ipa1.example.de
Directory Manager password:

Update in progress, 15 seconds elapsed
[ldap://ipa1.example.de:389] reports: Update failed! Status: [Error (-11)  - 
LDAP error: Connect error]


The slapd error logfile shows

[17/Jul/2019:09:43:31.711035365 +0200] - ERR - setup_ol_tls_conn - failed: 
unable to create new TLS context - -1
[17/Jul/2019:09:43:31.716241164 +0200] - ERR - slapi_ldap_init_ext - failed: 
unable to set SSL/TLS options
[17/Jul/2019:09:43:31.724077230 +0200] - ERR - setup_ol_tls_conn - failed: 
unable to create new TLS context - -1
[17/Jul/2019:09:43:31.732212109 +0200] - ERR - slapi_ldap_init_ext - failed: 
unable to set SSL/TLS options
[17/Jul/2019:09:43:31.740314529 +0200] - ERR - slapi_ldap_bind - Error: could 
not send startTLS request: error -11 (Connect error) errno 2 (No such file or 
directory)
[17/Jul/2019:09:43:31.753988317 +0200] - ERR - slapi_ldap_bind - Error: could 
not send startTLS request: error -11 (Connect error) errno 2 (No such file or 
directory)


Is there some way to roll back ipa1 to the old certificate, to
make replication work again? There must be some way out of this
mess.


Every helpful comment is highly appreciated
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

On 7/16/19 11:39 AM, François Cami wrote:


Please have a look at the latest logs from pki:
/var/log/pki/pki-tomcat/ca/



The debug log file on ipa2 gives me an authentication failed for
connecting to ldap on ipa2:

[16/Jul/2019:09:52:22][localhost-startStop-1]: 

[16/Jul/2019:09:52:22][localhost-startStop-1]: =  DEBUG SUBSYSTEM 
INITIALIZED   ===
[16/Jul/2019:09:52:22][localhost-startStop-1]: 

[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: restart at 
autoShutdown? false
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: autoShutdown crumb 
file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: about to look for 
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: found 
cert:auditSigningCert cert-pki-ca
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: done init id=debug
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: initialized debug
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: initSubsystem id=log
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: ready to init id=log
[16/Jul/2019:09:52:22][localhost-startStop-1]: Event filters:
[16/Jul/2019:09:52:22][localhost-startStop-1]: Creating 
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit)
[16/Jul/2019:09:52:22][localhost-startStop-1]: Event filters:
[16/Jul/2019:09:52:22][localhost-startStop-1]: Creating 
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system)
[16/Jul/2019:09:52:22][localhost-startStop-1]: Event filters:
[16/Jul/2019:09:52:22][localhost-startStop-1]: Creating 
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions)
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: restart at 
autoShutdown? false
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: autoShutdown crumb 
file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: about to look for 
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: found 
cert:auditSigningCert cert-pki-ca
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: done init id=log
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: initialized log
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: initSubsystem id=jss
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: ready to init id=jss
[16/Jul/2019:09:52:22][localhost-startStop-1]: JssSubsystem: initializing JSS 
subsystem
[16/Jul/2019:09:52:22][localhost-startStop-1]: JssSubsystem: enabled: true
[16/Jul/2019:09:52:22][localhost-startStop-1]: JssSubsystem: NSS database: 
/var/lib/pki/pki-tomcat/alias/
[16/Jul/2019:09:52:22][localhost-startStop-1]: JssSubsystem: initializing 
CryptoManager
[16/Jul/2019:09:52:22][localhost-startStop-1]: JssSubsystem: initializing SSL
[16/Jul/2019:09:52:22][localhost-startStop-1]: JssSubsystem: random:
[16/Jul/2019:09:52:22][localhost-startStop-1]: JssSubsystem: - algorithm: 
pkcs11prng
[16/Jul/2019:09:52:22][localhost-startStop-1]: JssSubsystem: - provider: 
Mozilla-JSS
[16/Jul/2019:09:52:22][localhost-startStop-1]: JssSubsystem: initialization 
complete
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: restart at 
autoShutdown? false
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: autoShutdown crumb 
file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: about to look for 
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: found 
cert:auditSigningCert cert-pki-ca
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: done init id=jss
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: initialized jss
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: initSubsystem id=dbs
[16/Jul/2019:09:52:22][localhost-startStop-1]: CMSEngine: ready to init id=dbs
[16/Jul/2019:09:52:22][localhost-startStop-1]: DBSubsystem: init()  
mEnableSerialMgmt=true
[16/Jul/2019:09:52:22][localhost-startStop-1]: Creating 
LdapBoundConnFactor(DBSubsystem)
[16/Jul/2019:09:52:22][localhost-startStop-1]: LdapBoundConnFactory: init
[16/Jul/2019:09:52:22][localhost-startStop-1]: LdapBoundConnFactory:doCloning 
true
[16/Jul/2019:09:52:22][localhost-startStop-1]: LdapAuthInfo: init()
[16/Jul/2019:09:52:22][localhost-startStop-1]: LdapAuthInfo: init begins
[16/Jul/2019:09:52:22][localhost-startStop-1]: LdapAuthInfo: init ends
[16/Jul/2019:09:52:22][localhost-startStop-1]: init: before makeConnection 
errorIfDown is true
[16/Jul/2019:09:52:22][localhost-startStop-1]: makeConnection: errorIfDown true
[16/Jul/2019:09:52:22][localhost-startStop-1]: TCP Keep-Alive: true
[16/Jul/2019:09:52:22][localhost-startStop-1]: 
ldapconn/PKISocketFactory.makeSSLSock

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

On 7/15/19 9:51 PM, Rob Crittenden wrote:




Please check the status again. POST_SAVED_CERT is the status where the
post command is being executed. It should be in MONITORING now.



Yes, it does. I had to resubmit a few other certificates, and now the
ca-error is gone on all ipa servers, too.

Now I get this on restarting ipa:

[root@ipa2 ~]# ipactl start
Existing service file detected!
Assuming stale, cleaning and proceeding
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting httpd Service
Starting ipa-custodia Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Shutting down
Hint: You can use --ignore-service-failure option for forced start in case that 
a non-critical service failed
Aborting ipactl

See below for Catalina's log file.


Every helpful comment is highly appreciated
Harri
Jul 16, 2019 9:52:16 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with JAR file [/usr/share/pki/server/common/lib/symkey.jar], exists: [false], canRead: [false]
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'enableOCSP' to 'false' did not find a matching property.
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderURL' to 'http://ipa2.example.de:9080/ca/ocsp' did not find a matching property.
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a matching property.
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspCacheSize' to '1000' did not find a matching property.
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspMinCacheEntryDuration' to '60' did not find a matching property.
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspMaxCacheEntryDuration' to '120' did not find a matching property.
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspTimeout' to '10' did not find a matching property.
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'strictCiphers' to 'true' did not find a matching property.
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'sslOptions' to 'ssl2=false,ssl3=false,tls=true' did not find a matching property.
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ssl2Ciphers' to '-SSL2_RC4_128_WITH_MD5,-SSL2_RC4_128_EXPORT40_WITH_MD5,-SSL2_RC2_128_CBC_WITH_MD5,-SSL2_RC2_128_CBC_EXPORT40_WITH_MD5,-SSL2_DES_64_CBC_WITH_MD5,-SSL2_DES_192_EDE3_CBC_WITH_MD5' did not find a matching property.
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ssl3Ciphers' to '-SSL3_FORTEZZA_DMS_WITH_NULL_SHA,-SSL3_FORTEZZA_DMS_WITH_RC4_128_SHA,+SSL3_RSA_WITH_RC4_128_SHA,-SSL3_RSA_EXPORT_WITH_RC4_40_MD5,+SSL3_RSA_WITH_3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_DES_CBC_SHA,-SSL3_RSA_EXPORT_WITH_RC2_CBC_40_MD5,-SSL3_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA,-SSL_RSA_FIPS_WITH_DES_CBC_SHA,+SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_NULL_MD5,-TLS_RSA_EXPORT1024_WITH_RC4_56_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA' did not find a matching property.
Jul 16, 2019 9:52:17 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'tlsCiphers' to '-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,+TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_DSS_WITH_AES_128_CBC_SHA,+TLS_DHE_DSS_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_RSA_W

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi folks,

On 7/15/19 2:41 PM, Harald Dunkel via FreeIPA-users wrote:


Good news (sort of): ipa does *not* appear to be out of sync. Some
new user accounts added recently can be found in ldap on all ipa
servers.  It just failed to distribute the new certificate.

Every suggestion about how to add the lost certificate to ipa0 and
the others is highly welcome.



I found a similar incident on this mailing list.

https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WIR436TCS5EV7P7OPRSEY2RYYXDLRS7G/

The recommendation was to resubmit the request id via getcert. This is what I 
tried:


[root@ipa2 log]# getcert list -n "subsystemCert cert-pki-ca"
Number of certificates and requests being tracked: 9.
Request ID '20181031075940':
status: MONITORING
ca-error: Invalid cookie: u''
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert 
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=example AG,C=DE
subject: CN=CA Subsystem,O=example AG,C=DE
expires: 2019-08-01 08:06:59 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert 
cert-pki-ca"
track: yes
auto-renew: yes
[root@ipa2 log]# getcert resubmit -i 20181031075940
Resubmitting "20181031075940" to "dogtag-ipa-ca-renew-agent".
[root@ipa2 log]# getcert list -n "subsystemCert cert-pki-ca"
Number of certificates and requests being tracked: 9.
Request ID '20181031075940':
status: POST_SAVED_CERT
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert 
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=example AG,C=DE
subject: CN=CA Subsystem,O=example AG,C=DE
expires: 2021-06-23 09:56:18 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert 
cert-pki-ca"
track: yes
auto-renew: yes

AFAICT the new certificate is available on ipa2 now, but ldap was not
updated :-(.

Please note the "invalid cookie" and the new status "POST_SAVED_CERT".
Is this as expected?


Every helpful comment is highly appreciated.
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Flo,

On 7/15/19 11:53 AM, Harald Dunkel wrote:

Hi Flo,

On 7/11/19 7:58 PM, Florence Blanc-Renaud via FreeIPA-users wrote:


I hate to bring bad news, but it really looks like replication failed between 
your instances. Feel free to start a new thread on the users mailing list if 
you need assistance.



Wouldn't you agree that freeipa should net get out of sync when
the certificate is renewed? It would be very nice if this issue
could be fixed.



Good news (sort of): ipa does *not* appear to be out of sync. Some
new user accounts added recently can be found in ldap on all ipa
servers.  It just failed to distribute the new certificate.

Every suggestion about how to add the lost certificate to ipa0 and
the others is highly welcome.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: unregister old EMail address on this mailing list?

[Harald Dunkel via FreeIPA-users]

Hi Flo,

On 7/11/19 7:54 PM, Florence Blanc-Renaud wrote:


Hi Harri,

you probably didn't notice this footer in the emails sent to freeipa-users:

To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

It may be worth a try...



That would unsubscribe the *valid* IP address. I wouldn't be able to
post here anymore.

As written before, I cannot send EMails using the old address. It is
masqueraded by our sendmail to the new address.


I am really sorry to bother you with this. I can live with receiving
some EMails twice or thrice, but maybe you should consider to activate
the web interface in mailman for unsubscribing.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Flo,

On 7/11/19 7:58 PM, Florence Blanc-Renaud via FreeIPA-users wrote:

On 7/11/19 10:19 AM, Harald Dunkel via FreeIPA-users wrote:


The ldapsearch line returns 2 identical certificates on ipa{0,1,2,bak},
but ipa1 has a 3rd certificate.

Please don't tell me that my ldap instances are out of sync again.


I hate to bring bad news, but it really looks like replication failed between 
your instances. Feel free to start a new thread on the users mailing list if 
you need assistance.



Wouldn't you agree that freeipa should net get out of sync when
the certificate is renewed? It would be very nice if this issue
could be fixed.

The assumption here is, that freeipa was in sync *before* ipa1
tried to renew the certificate. Is there some way to verify that
the renewal did or did not break synchronization?


Coming back to your original issue, ipa host-del should work if executed on 
ipa1 (the one with the renewed cert).



Unfortunately it doesn't:

[root@ipa1 ~]# ipa host-del ppcl027.ac.aixigo.de
ipa: ERROR: Certificate operation cannot be completed: Unable to communicate 
with CMS (404)


Every helpful comment is highly appreciated
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] unregister old EMail address on this mailing list?

[Harald Dunkel via FreeIPA-users]

Hi folks,

I have a new EMail address.

Problem is, there is no option on [Manage subscription] to replace
the EMail address. The old address is not available to send an
unsubscribe to mailman, either. I could subscribe my new address
via mail to mailman, but

https://lists.fedorahosted.org/admin/accounts/subscriptions/

doesn't show these subscriptions, either.

Since the old address is still valid for receiving mails I get all
EMails twice now. How can I unsubscribe the old EMail address from
freeipa-users and freeipa-devel?


Every helpful comment is highly appreciated
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi Florence,

On 7/10/19 4:50 PM, Florence Blanc-Renaud wrote:


Hi,
the issue seems rather to be between IPA framework and dogtag. Is the CA 
subsystem enabled?
$ pki-server subsystem-show ca
should display "Enabled: True"



Nope:

[root@ipa1 ~]# pki-server subsystem-show ca
  Subsystem ID: ca
  Instance ID: pki-tomcat
  Enabled: False

Freeipa's top level certificate was signed by an external CA.


The subsystem logs may show more information: /var/log/pki/pki-tomcat/ca/debug


As you might have imagined, this doesn't exist, either.


I would start by checking if the "subsystemCert cert-pki-ca" certificate is 
still valid and consistent in the NSSDB and in ldap:
$ certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' | grep 
"Not After"
=> check the date



I've got 4 ipa servers with a local certificate database. One ipa server (ipa1)
gives me

[root@ipa1 ~]# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' | 
grep "Not After"
Not After : Wed Jun 23 09:56:18 2021

The other 3 say

[root@ipa0 ~]# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' | 
grep "Not After"
Not After : Thu Aug 01 08:06:59 2019

[root@ipa2 ~]# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' | 
grep "Not After"
Not After : Thu Aug 01 08:06:59 2019

[root@ipabak ~]# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' 
| grep "Not After"
Not After : Thu Aug 01 08:06:59 2019

Obviously the certificate got renewed on ipa1, but not on the others.


$ certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' -a
$ ldapsearch -D cn=directory\ manager -W -b o=ipaca uid=pkidbuser 
userCertificate
Both commands should return the same content for the certificate



The ldapsearch line returns 2 identical certificates on ipa{0,1,2,bak},
but ipa1 has a 3rd certificate.

Please don't tell me that my ldap instances are out of sync again.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi folks,

Setup: ipa-server 4.6.4-7 on CentOS 7

Problem:
ipa host-del gives me

[root@ipa1 ~]# ipa host-del ppcl027.example.com
ipa: ERROR: Certificate operation cannot be completed: Unable to communicate 
with CMS (404)

Google pointed me to https://access.redhat.com/solutions/3624671,
but AFAICS this fix is not applicable. "^/ca/rest/certs/search" is
already in

:
# matches for CA REST API

NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate
NSSVerifyClient optional
ProxyPassMatch ajp://localhost:8009
ProxyPassReverse ajp://localhost:8009

:


?

Every helpful comment is highly appreciated
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (404)

[Harald Dunkel via FreeIPA-users]

Hi folks,

Setup: ipa-server 4.6.4-7 on CentOS 7

Problem:
ipa host-del gives me

[root@ipa1 ~]# ipa host-del ppcl027.example.com
ipa: ERROR: Certificate operation cannot be completed: Unable to communicate 
with CMS (404)

Google pointed me to https://access.redhat.com/solutions/3624671,
but AFAICS this fix is not applicable. "^/ca/rest/certs/search" is
already in

:
# matches for CA REST API

NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate
NSSVerifyClient optional
ProxyPassMatch ajp://localhost:8009
ProxyPassReverse ajp://localhost:8009

:


?

Every helpful comment is highly appreciated
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: is anyone running Debian as freeipa-client

[Harald Dunkel via FreeIPA-users]

Hi Eric,

On 1/10/19 2:33 PM, Eric Engstrom via FreeIPA-users wrote:
> 
>> I am using freeipa 4.4.4-3 and sssd 1.16.3-1 on Stretch. Just the
>> client part of freeipa, of course. Requires systemd for running
>> ipa-client-install, but it works fine for me.
> 
> Harald,
> 
> Could you be a bit more specific about the method of installing a client on 
> stretch?  Are you downloading the packages manually and installing via dpkg 
> or what repositories are you referencing to get apt* to do the right thing - 
> presumably sid/unstable if the latter...
> 

I manually picked up the freeipa packages for Sid and added them
to my local backports repository for Stretch (without rebuild). I
*did* a local backport of sssd 1.16.3-1, though.

ipa-client-install command line on Stretch:

  ipa-client-install --no-ssh --no-sshd --no-nisdomain --no-sudo --no-ntp 
--no-dns-sshfp
  sed -i.bak -e 's/compat/files/g' -e 's/^sudoers\:/\#sudoers\:/' 
/etc/nsswitch.conf

Your mileage may vary, of course.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: is anyone running Debian as freeipa-client

[Harald Dunkel via FreeIPA-users]

Hi Johan,

I am using freeipa 4.4.4-3 and sssd 1.16.3-1 on Stretch. Just the
client part of freeipa, of course. Requires systemd for running
ipa-client-install, but it works fine for me.

My ipa servers are running on CentOS 7.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: is running sssd and nscd in parallel a better option?

[Harald Dunkel via FreeIPA-users]

Hi Jakub,

On 9/21/18 3:24 PM, Jakub Hrozek via FreeIPA-users wrote:

On Wed, Sep 19, 2018 at 02:04:28PM +0200, Harald Dunkel via FreeIPA-users wrote:

I still have the problem that sometimes some sssd components
disappear somehow, e.g. sssd_pam. The logfile on our mail gateway
said

:
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
with result [0]: Success.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [filter_responses] (0x0100): 
[pam_response_filter] not available, not fatal.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 74
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0010): Reply 
error.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
with result [4]: System error.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [filter_responses] (0x0100): 
[pam_response_filter] not available, not fatal.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 26
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0010): Reply 
error.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
with result [4]: System error.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [filter_responses] (0x0100): 
[pam_response_filter] not available, not fatal.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 26
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0080): Client 
already disconnected
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0080): Client 
already disconnected
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0020): Performing 
auto-reconnect
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.


This indicated a crash in sssd_be...I don't know Debian almost at all,
but I would check the syslog for evidence..



According to syslog the services were shut down and restarted for an
unknown reason:

Sep 18 22:32:30 srvvm01 sssd[pam]: Shutting down
Sep 18 22:32:31 srvvm01 sssd[pam]: Starting up
Sep 18 22:34:11 srvvm01 sssd[nss]: Shutting down
Sep 18 22:34:12 srvvm01 sssd[nss]: Starting up
Sep 18 22:34:28 srvvm01 sssd[be[example.de]]: Shutting down
Sep 18 22:34:28 srvvm01 sssd[be[example.de]]: Starting up

No crash. Please note that other sssd services were *not* restarted.


???
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] is running sssd and nscd in parallel a better option?

[Harald Dunkel via FreeIPA-users]

Hi folks,

I read somewhere that it is not recommended to run nscd to cache
passwd on ipa clients, but I wonder: What if?

I still have the problem that sometimes some sssd components
disappear somehow, e.g. sssd_pam. The logfile on our mail gateway
said

:
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
with result [0]: Success.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [filter_responses] (0x0100): 
[pam_response_filter] not available, not fatal.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 74
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0010): Reply 
error.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
with result [4]: System error.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [filter_responses] (0x0100): 
[pam_response_filter] not available, not fatal.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 26
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0010): Reply 
error.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
with result [4]: System error.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [filter_responses] (0x0100): 
[pam_response_filter] not available, not fatal.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 26
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0080): Client 
already disconnected
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [pam_dp_process_reply] (0x0080): Client 
already disconnected
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0020): Performing 
auto-reconnect
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
(Tue Sep 18 22:34:28 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
:
:
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [pam_dom_forwarder] (0x0100): 
pam_dp_send_req returned 11
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
with result [4]: System error.
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [filter_responses] (0x0100): 
[pam_response_filter] not available, not fatal.
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 26
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [client_recv] (0x0200): Client 
disconnected!
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_dispatch] (0x0400): SBUS is 
reconnecting. Deferring.
:
:
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_reconnect] (0x0080): Making 
reconnection attempt 1 to 
[unix:path=/var/lib/sss/pipes/private/sbus-dp_aixigo.de]
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_reconnect] (0x0080): Reconnected 
to [unix:path=/var/lib/sss/pipes/private/sbus-dp_aixigo.de]
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [sbus_conn_register_path] (0x0400): 
Registering object path /org/freedesktop/sssd/responder with D-Bus connection
(Tue Sep 18 22:34:29 2018) [sssd[pam]] [pam_dp_reconnect_init] (0x0020): 
Reconnected to the Data Provider.
:

Some EMails were bounced with user unknown at the same time, so I would
guess there is a coincidence. Question is, could nscd be an option here,
providing an additional cache for user accounts? What side effects could
come up?

Platform is Debian 9, sssd is version 1.16.2, nscd version 2.24.


Every helpful comment is highly appreciated.
Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: confused about ipa-dns-install not creating reverse zone

[Harald Dunkel via FreeIPA-users]

PS: The logfile says

2018-08-03T08:25:31Z INFO Checking DNS domain 10.0.10.in-addr.arpa., please 
wait ...
2018-08-03T08:26:01Z INFO Reverse zone 10.0.10.in-addr.arpa. for IP address 
10.0.10.7 already exists


But I doubt that this is correct. dig returns

[root@idms00 centos]# dig -x 10.0.10.7

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> -x 10.0.10.7
;; global options: +cmd
;; connection timed out; no servers could be reached

[root@idms00 centos]# dig @1.1.1.1 -x 10.0.10.7

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @1.1.1.1 -x 10.0.10.7
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6695
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;7.10.0.10.in-addr.arpa.IN  PTR

;; AUTHORITY SECTION:
7.10.0.10.in-addr.arpa. 10800   IN  SOA nobody.invalid. nobody.invalid. 
1 3600 1200 604800 10800

;; ADDITIONAL SECTION:
explanation.invalid.10800   IN  TXT "Blocking is mandated by standards, 
see references on 
https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml";

;; Query time: 3 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Aug 03 08:32:50 UTC 2018
;; MSG SIZE  rcvd: 274



I wonder how this is supposed to work?

Every insightful comment is highly appreciated.
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/VZ5FKEPKTCLG7KHQQC4NXDWWKWPKHLFN/

[Freeipa-users] confused about ipa-dns-install not creating reverse zone

[Harald Dunkel via FreeIPA-users]

Hi folks,

I am confused: Setting up a new freeipa service (CentOS 7.5) using
ipa-server-install or ipa-dns-install it asks me

Do you want to search for missing reverse zones? [yes]: yes

But then it did not create a reverse zone :-(.

This doesn't look like documented. There is no "--no-reverse", it
did not list any reverse zones it has found, so it should have asked
"Do you want to configure the reverse zone?".

How can I tell ipa-dns-install to create a reverse zone (no matter
what), suitable for dynamic updates, before it adds its own host
name and IPv4 address to the database?


Every helpful comment is highly appreciated.
Harri
-

[root@idms01 centos]# ipa-dns-install

The log file for this installation can be found in 
/var/log/ipaserver-install.log
==
This program will setup DNS for the IPA Server.

This includes:
  * Configure DNS (bind)
  * Configure SoftHSM (required by DNSSEC)
  * Configure ipa-dnskeysyncd (required by DNSSEC)

NOTE: DNSSEC zone signing is not enabled by default


To accept the default shown in brackets, press the Enter key.

Do you want to configure DNS forwarders? [yes]:
Following DNS servers are configured in /etc/resolv.conf: 127.0.0.1
Do you want to configure these servers as DNS forwarders? [yes]: no
Enter an IP address for a DNS forwarder, or press Enter to skip: 1.1.1.1
DNS forwarder 1.1.1.1 added. You may add another.
Enter an IP address for a DNS forwarder, or press Enter to skip:
Checking DNS forwarders, please wait ...
Do you want to search for missing reverse zones? [yes]: yes

The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Configuring DNS (named)
  [1/9]: generating rndc key file
  [2/9]: setting up our zone
  [3/9]: setting up our own record
  [4/9]: adding NS record to the zones
  [5/9]: setting up kerberos principal
  [6/9]: setting up named.conf
  [7/9]: setting up server configuration
  [8/9]: configuring named to start on boot
  [9/9]: changing resolv.conf to point to ourselves
Done configuring DNS (named).
Restarting the web server to pick up resolv.conf changes
Configuring DNS key synchronization service (ipa-dnskeysyncd)
  [1/7]: checking status
  [2/7]: setting up bind-dyndb-ldap working directory
  [3/7]: setting up kerberos principal
  [4/7]: setting up SoftHSM
  [5/7]: adding DNSSEC containers
  [6/7]: creating replica keys
  [7/7]: configuring ipa-dnskeysyncd to start on boot
Done configuring DNS key synchronization service (ipa-dnskeysyncd).
Restarting ipa-dnskeysyncd
Restarting named
Updating DNS system records
==
Setup complete

Global DNS configuration in LDAP server is empty
You can use 'dnsconfig-mod' command to set global DNS options that
would override settings in local named.conf files


You must make sure these network ports are open:
TCP Ports:
  * 53: bind
UDP Ports:
  * 53: bind
[root@idms01 centos]# ipa dnszone-find
  Zone name: example.eu.
  Active zone: TRUE
  Authoritative nameserver: idms01.example.eu.
  Administrator e-mail address: hostmaster.example.eu.
  SOA serial: 1533217523
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Allow query: any;
  Allow transfer: none;

Number of entries returned 1

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/BIU4WPD5VNVV6PHL3YCOFC3YX3YGWOAE/

[Freeipa-users] Do you want to search for missing reverse zones?

[Harald Dunkel via FreeIPA-users]

Hi folks,

I am confused: Setting up a new freeipa service (CentOS 7.5) using
ipa-server-install or ipa-dns-install it asks me

Do you want to search for missing reverse zones? [yes]: yes

But then it did not create a reverse zone :-( This doesn't look like
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/install-server

Is this a good thing? How can I tell ipa-dns-install to create a
reverse zone, no matter what?


Every helpful comment is highly appreciated.
Harri
-

[root@idms01 centos]# ls -al /etc/resolv.conf
ls: cannot access /etc/resolv.conf: No such file or directory
[root@idms01 centos]# ipa-dns-install

The log file for this installation can be found in 
/var/log/ipaserver-install.log
==
This program will setup DNS for the IPA Server.

This includes:
  * Configure DNS (bind)
  * Configure SoftHSM (required by DNSSEC)
  * Configure ipa-dnskeysyncd (required by DNSSEC)

NOTE: DNSSEC zone signing is not enabled by default


To accept the default shown in brackets, press the Enter key.

Do you want to configure DNS forwarders? [yes]:
Following DNS servers are configured in /etc/resolv.conf: 127.0.0.1
Do you want to configure these servers as DNS forwarders? [yes]: no
Enter an IP address for a DNS forwarder, or press Enter to skip: 1.1.1.1
DNS forwarder 1.1.1.1 added. You may add another.
Enter an IP address for a DNS forwarder, or press Enter to skip:
Checking DNS forwarders, please wait ...
Do you want to search for missing reverse zones? [yes]: yes

The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Configuring DNS (named)
  [1/8]: generating rndc key file
  [2/8]: setting up our own record
  [3/8]: adding NS record to the zones
  [4/8]: setting up kerberos principal
  [5/8]: setting up named.conf
  [6/8]: setting up server configuration
  [7/8]: configuring named to start on boot
  [8/8]: changing resolv.conf to point to ourselves
Done configuring DNS (named).
Restarting the web server to pick up resolv.conf changes
Configuring DNS key synchronization service (ipa-dnskeysyncd)
  [1/7]: checking status
  [2/7]: setting up bind-dyndb-ldap working directory
  [3/7]: setting up kerberos principal
  [4/7]: setting up SoftHSM
  [5/7]: adding DNSSEC containers
  [6/7]: creating replica keys
  [7/7]: configuring ipa-dnskeysyncd to start on boot
Done configuring DNS key synchronization service (ipa-dnskeysyncd).
Restarting ipa-dnskeysyncd
Restarting named
Updating DNS system records
==
Setup complete

Global DNS configuration in LDAP server is empty
You can use 'dnsconfig-mod' command to set global DNS options that
would override settings in local named.conf files


You must make sure these network ports are open:
TCP Ports:
  * 53: bind
UDP Ports:
  * 53: bind
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/ONKHGY5OIPVYLCG7JTDTIR6APUI35R5E/

[Freeipa-users] openldap and freeipa

[Harald Dunkel via FreeIPA-users]

Hi folks,

apparently openldap-server is considered as deprecated by RedHat:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.4_release_notes/chap-red_hat_enterprise_linux-7.4_release_notes-deprecated_functionality

I wonder what this means for Freeipa? Will all of openldap fall
behind?


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/24KUPVQ54LUU4ZHRX6VRDTK2EB4HFA7R/

[Freeipa-users] sssd is going down and up and down and up and down and ... until it breaks

[Harald Dunkel via FreeIPA-users]

Hi folks,

Apparently sssd goes down and up again and again. I found this in
/var/log/daemon.log on our git server:

Jul 23 18:02:08 git01 sssd[be[example.de]]: Shutting down
Jul 23 18:02:08 git01 sssd[pam]: Shutting down
Jul 23 18:02:08 git01 sssd[nss]: Shutting down
Jul 23 18:02:09 git01 sssd[pam]: Starting up
Jul 23 18:02:09 git01 sssd[nss]: Starting up
Jul 23 18:02:09 git01 sssd[be[example.de]]: Starting up
Jul 23 18:02:11 git01 sssd[nss]: Starting up
Jul 23 18:02:11 git01 sssd[pam]: Starting up
Jul 23 20:01:33 git01 sssd[nss]: Shutting down
Jul 23 20:01:33 git01 sssd[pam]: Shutting down
Jul 23 20:01:33 git01 sssd[be[example.de]]: Shutting down
Jul 23 20:01:33 git01 sssd[nss]: Starting up
Jul 23 20:01:33 git01 sssd[pam]: Starting up
Jul 23 20:01:33 git01 sssd[be[example.de]]: Starting up
Jul 23 20:01:35 git01 sssd[nss]: Starting up
Jul 23 20:01:35 git01 sssd[pam]: Starting up
Jul 23 20:02:44 git01 sssd[nss]: Shutting down
Jul 23 20:02:44 git01 sssd[nss]: Starting up
Jul 23 20:03:43 git01 sssd[nss]: Shutting down
Jul 23 20:03:43 git01 sssd[pam]: Shutting down
Jul 23 20:03:43 git01 sssd[nss]: Starting up
Jul 23 20:03:43 git01 sssd[pam]: Starting up
Jul 23 20:06:24 git01 sssd[be[example.de]]: Shutting down
Jul 23 20:06:24 git01 sssd[be[example.de]]: Starting up
Jul 23 20:07:34 git01 sssd[be[example.de]]: Shutting down
Jul 23 20:07:37 git01 sssd[pam]: Shutting down
Jul 23 20:07:37 git01 sssd[be[example.de]]: Starting up
Jul 23 20:07:37 git01 sssd[pam]: Starting up
Jul 23 20:07:37 git01 sssd[pam]: Starting up
Jul 23 20:14:39 git01 sssd[pam]: Shutting down
Jul 23 20:14:39 git01 sssd[be[example.de]]: Starting up
Jul 23 20:14:39 git01 sssd[pam]: Starting up
Jul 23 20:18:44 git01 sssd[be[example.de]]: Shutting down
Jul 23 20:18:44 git01 sssd[pam]: Shutting down
Jul 23 20:18:44 git01 sssd[be[example.de]]: Starting up
Jul 23 20:18:44 git01 sssd[pam]: Starting up
Jul 24 04:05:28 git01 sssd[pam]: Shutting down
Jul 24 04:05:28 git01 sssd[pam]: Starting up
Jul 24 05:21:53 git01 sssd[be[example.de]]: Shutting down
Jul 24 05:21:53 git01 sssd[be[example.de]]: Starting up
Jul 24 05:27:50 git01 sssd[pam]: Shutting down
Jul 24 05:27:50 git01 sssd[pam]: Starting up
Jul 24 05:27:50 git01 sssd[be[example.de]]: Starting up
Jul 24 05:27:53 git01 sssd[pam]: Starting up
Jul 24 05:30:31 git01 sssd[pam]: Shutting down
Jul 24 05:30:31 git01 sssd[pam]: Starting up
Jul 24 05:31:59 git01 sssd[nss]: Shutting down
Jul 24 05:31:59 git01 sssd[pam]: Shutting down
Jul 24 05:31:59 git01 sssd[nss]: Starting up
Jul 24 05:31:59 git01 sssd[be[example.de]]: Shutting down
Jul 24 05:31:59 git01 sssd[pam]: Starting up
Jul 24 05:31:59 git01 sssd[be[example.de]]: Starting up
Jul 24 05:32:01 git01 sssd[pam]: Starting up
Jul 24 05:33:24 git01 sssd[pam]: Shutting down
Jul 24 05:33:24 git01 sssd[pam]: Starting up
Jul 24 05:33:24 git01 sssd[be[example.de]]: Starting up
Jul 24 06:01:38 git01 sssd[pam]: Shutting down
Jul 24 06:01:38 git01 sssd[be[example.de]]: Starting up
Jul 24 06:01:38 git01 sssd[pam]: Starting up
Jul 24 06:02:39 git01 sssd[be[example.de]]: Shutting down
Jul 24 06:02:39 git01 sssd[be[example.de]]: Starting up
Jul 24 09:56:52 git01 sssd[pam]: Shutting down
Jul 24 09:56:52 git01 sssd[pam]: Starting up
Jul 24 10:02:42 git01 sssd[nss]: Shutting down
Jul 24 10:02:42 git01 sssd[pam]: Shutting down
Jul 24 10:02:42 git01 sssd[nss]: Starting up
Jul 24 10:02:42 git01 sssd[pam]: Starting up
Jul 24 10:02:42 git01 sssd[nss]: Shutting down
Jul 24 10:02:42 git01 sssd[pam]: Shutting down
Jul 24 10:02:42 git01 sssd[nss]: Starting up
Jul 24 10:02:42 git01 sssd[pam]: Starting up
Jul 24 10:02:42 git01 sssd[be[example.de]]: Shutting down
Jul 24 10:02:42 git01 sssd[be[example.de]]: Starting up
Jul 24 10:06:14 git01 sssd[be[example.de]]: Shutting down
Jul 24 10:06:14 git01 sssd[nss]: Shutting down
Jul 24 10:06:14 git01 sssd[nss]: Starting up
Jul 24 10:06:14 git01 sssd[be[example.de]]: Starting up
Jul 24 10:06:14 git01 sssd[nss]: Starting up
Jul 24 10:15:49 git01 sssd[be[example.de]]: Shutting down
Jul 24 10:15:49 git01 sssd[be[example.de]]: Starting up
Jul 24 10:16:44 git01 sssd[be[example.de]]: Shutting down
Jul 24 10:17:00 git01 sssd[pam]: Shutting down
Jul 24 10:17:00 git01 sssd[pam]: Starting up
Jul 24 10:17:00 git01 sssd[be[example.de]]: Starting up
Jul 24 10:17:00 git01 sssd[pam]: Starting up
Jul 24 10:18:48 git01 sssd[pam]: Shutting down
Jul 24 10:18:48 git01 sssd[pam]: Starting up
Jul 24 10:19:43 git01 sssd[be[example.de]]: Shutting down
Jul 24 10:19:43 git01 sssd[be[example.de]]: Starting up
Jul 24 10:20:32 git01 sssd[pam]: Shutting down
Jul 24 10:20:32 git01 sssd[pam]: Starting up
Jul 24 10:21:12 git01 sssd[be[example.de]]: Shutting down
Jul 24 10:21:15 git01 sssd[be[example.de]]: Starting up
Jul 24 10:27:11 git01 sssd[be[example.de]]: Shutting down
Jul 24 10:27:11 git01 sssd[pam]: Shutting down
Jul 24 10:27:11 git01 sssd[pam]: Starting up
Jul 24 10:27:11 git01 sssd[be[example.de]]: Starting up
Jul 24 10:27:13 git01 sssd[pam]: Starting up
Jul 24 10:30:

[Freeipa-users] Re: certmonger upgrade failure

[Harald Dunkel via FreeIPA-users]

Hi folks,

On 6/28/18 9:08 AM, Harald Dunkel via FreeIPA-users wrote:

On 6/27/18 5:59 PM, Rob Crittenden via FreeIPA-users wrote:


I don't see anything obviously wrong. I'd try launching certmonger from
a shell to see what you get:

# certmonger -d 9



certmonger works fine on the command line, AFAICT.
I think this is the problem:

# systemctl status certmonger
Failed to get D-Bus connection: Connection refused
# systemctl status
Failed to get D-Bus connection: Connection refused
# ps -ef | grep -i b[u]s
dbus    58 1  0 Jun23 ?    00:00:00 /usr/bin/dbus-daemon --system 
--address=systemd: --nofork --nopidfile --systemd-activation



I found the problem. Obviously dbus started to use /run/dbus/system_bus_socket
instead of /var/run/dbus/system_bus_socket, forcing everybody else to either
change the path in their code (nobody did) or to establish a symlink for
/var/run pointing to /run *before* the upgrade to 7.5 (nobody did, either).


Thanx for your help and support
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/JPIY65FQDQPYMJ3NVZ2EWXQKEWAIDTKB/

[Freeipa-users] Re: certmonger upgrade failure

[Harald Dunkel via FreeIPA-users]

On 6/28/18 2:19 PM, Harald Dunkel via FreeIPA-users wrote:


The dbus problem has been resolved by reinstalling the dbus RPMs.
journalctl still shows a lot of "Connection refused" messages for
dbus, see attachment.

certmonger appears to be running when started on the command line
(does it?), but it cannot be started by systemd at boot time, still.
Attached you will also find the output of "certmonger -d 9".


Hope this helps. Every insightful comment is highly appreciated
Harri



Anybody to the rescue?


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/EH4EBLRHZGUJZLITCARTUXN2GVOJQPKS/

[Freeipa-users] Re: certmonger upgrade failure

[Harald Dunkel via FreeIPA-users]

On 6/27/18 5:59 PM, Rob Crittenden via FreeIPA-users wrote:


I don't see anything obviously wrong. I'd try launching certmonger from
a shell to see what you get:

# certmonger -d 9



certmonger works fine on the command line, AFAICT.
I think this is the problem:

# systemctl status certmonger
Failed to get D-Bus connection: Connection refused
# systemctl status
Failed to get D-Bus connection: Connection refused
# ps -ef | grep -i b[u]s
dbus58 1  0 Jun23 ?00:00:00 /usr/bin/dbus-daemon --system 
--address=systemd: --nofork --nopidfile --systemd-activation


Dbus is running, but it doesn't work. There is no error message
on the console at boot time, but journalctl -b shows

:
Jun 28 08:28:36 ipa1.example.de systemd[1]: Reached target Basic System.
Jun 28 08:28:36 ipa1.example.de systemd[1]: Starting Basic System.
Jun 28 08:28:36 ipa1.example.de systemd[1]: Started D-Bus System Message Bus.
Jun 28 08:28:36 ipa1.example.de systemd[1]: Failed to connect to system bus: 
Connection refused
Jun 28 08:28:36 ipa1.example.de systemd[1]: Failed to initialize D-Bus 
connection: Connection refused
Jun 28 08:28:36 ipa1.example.de systemd[1]: Starting D-Bus System Message Bus...
Jun 28 08:28:36 ipa1.example.de systemd[1]: Starting System Security Services 
Daemon...
Jun 28 08:28:36 ipa1.example.de systemd[1]: Starting Resets System Activity 
Logs...
Jun 28 08:28:36 ipa1.example.de systemd[1]: Started irqbalance daemon.
Jun 28 08:28:36 ipa1.example.de systemd[1]: Starting irqbalance daemon...
:


Maybe this is OT here?


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/VPICGQUE5ASRZBYU6BSO23ZNKHESCFUK/

[Freeipa-users] Re: certmonger upgrade failure

[Harald Dunkel via FreeIPA-users]

Hi Rob,

On 6/25/18 7:10 PM, Rob Crittenden via FreeIPA-users wrote:

Harald Dunkel via FreeIPA-users wrote:


I found https://bugzilla.redhat.com/show_bug.cgi?id=1519206, but the conclusion
("please reboot") is not helpful. I did.


The dbus developers don't think it should ever be restarted mid-stream.
I suppose they have their reasons.



I am not sure what you mean by "restarted mid-stream". Does rpm know?
Is there a risk at upgrade time?


I'd need to see the contents of /var/lib/certmonger/requests/* to try to
figure out what is bogging things down.

NOTE: THERE MAY BE EMBEDDED PASSWORDS IN THOSE FILES. PLEASE DO NOT
PASTE TO A PUBLIC LIST.

But I do need to see whether there is a PIN at all so for any key_pin=
just replace with key_pin=XXX or something.



I see several files with a key_pin or Key_pin_file inside. I would prefer
to send you these files in an encrypted EMail. What would you suggest? Do
you have PGP?


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/KYYXX23R2CN2AZOJCRKOZPCN5TJD2CTK/

[Freeipa-users] Re: certmonger upgrade failure

[Harald Dunkel via FreeIPA-users]

Hi Rob,

On 6/25/18 4:53 PM, Rob Crittenden via FreeIPA-users wrote:
> 
> We'd need to see what certs are being tracked, getcert list.
> 

This gets stuck, too:

[root@ipa1 ~]# getcert list
Error org.freedesktop.DBus.Error.TimedOut

I found https://bugzilla.redhat.com/show_bug.cgi?id=1519206, but the conclusion
("please reboot") is not helpful. I did.

On an ipa replica still running CentOS 7.4 I get the attached list of 
certificates.
Hope this helps.


Regards
Harri
Number of certificates and requests being tracked: 9.
Request ID '20171020103020':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
CA: SelfSign
issuer: CN=ipa2.example.de,O=example AG,C=DE
subject: CN=ipa2.example.de,O=example AG,C=DE
expires: 2018-10-20 10:30:20 UTC
principal name: krbtgt/example...@example.de
certificate template/profile: KDCs_PKINIT_Certs
pre-save command: 
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
Request ID '20180115065920':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=example AG,C=DE
subject: CN=CA Audit,O=example AG,C=DE
expires: 2019-08-01 08:08:20 UTC
key usage: digitalSignature,nonRepudiation
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20180115065921':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert 
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=example AG,C=DE
subject: CN=OCSP Subsystem,O=example AG,C=DE
expires: 2019-08-01 08:07:56 UTC
eku: id-kp-OCSPSigning
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20180115065922':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert 
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=example AG,C=DE
subject: CN=CA Subsystem,O=example AG,C=DE
expires: 2019-08-01 08:06:59 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"subsystemCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20180115065923':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE
subject: CN=Certificate Authority,O=example AG,C=DE
expires: 2042-12-31 23:59:59 UTC
key usage: keyCertSign,cRLSign
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"caSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20180115065924':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=example AG,C=DE
subject: CN=IPA RA,O=example AG,C=DE
expires: 2019-08-01 08:06:26 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-client

[Freeipa-users] certmonger upgrade failure

[Harald Dunkel via FreeIPA-users]

Hi folks,

I managed to get rid of the corrupted entry and to create a new
user account. But there are still problems. The upgrade from Centos
7.4 to 7.5 got stuck for 5 to 10 minutes.

:
  Installing : libxkbcommon-0.7.1-1.el7.x86_64  297/787
  Updating   : adwaita-cursor-theme-3.26.0-1.el7.noarch 298/787
  Updating   : adwaita-icon-theme-3.26.0-1.el7.noarch   299/787
  Updating   : perl-Getopt-Long-2.40-3.el7.noarch   300/787
  Updating   : 389-ds-base-1.3.7.5-21.el7_5.x86_64  301/787
warning: /etc/sysconfig/dirsrv.systemd created as 
/etc/sysconfig/dirsrv.systemd.rpmnew
  Updating   : slapi-nis-0.56.0-8.el7.x86_64302/787
  Updating   : ipa-server-4.5.4-10.el7.centos.1.x86_64  303/787
Job for certmonger.service failed because a fatal signal was delivered to the control process. See 
"systemctl status certmonger.service" and "journalctl -xe" for details.
Job for dbus.service failed. See "systemctl status dbus.service" and "journalctl 
-xe" for details.
  Updating   : linux-firmware-20180220-62.2.git6d51311.el7_5.noarch 304/787
  Installing : kernel-3.10.0-862.3.3.el7.x86_64 305/787
  Installing : kmod-kvdo-6.1.0.168-16.el7_5.x86_64  306/787
  Updating   : 2:vim-filesystem-7.4.160-4.el7.x86_64307/787
  Updating   : libgcc-4.8.5-28.el7_5.1.i686 308/787
  Updating   : 2:vim-common-7.4.160-4.el7.x86_64309/787
:


After a reboot I got this in the ldap error log on ipa1:

[23/Jun/2018:10:58:55.823078141 +0200] - INFO - slapd_extract_cert - CA CERT 
NAME: CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE
[23/Jun/2018:10:58:55.829958313 +0200] - INFO - slapd_extract_cert - CA CERT 
NAME: EXAMPLE.DE IPA CA
[23/Jun/2018:10:58:55.842015522 +0200] - INFO - slapd_extract_cert - CA CERT 
NAME: EXAMPLE.DE IPA CA
[23/Jun/2018:10:58:55.84607 +0200] - WARN - Security Initialization - SSL 
alert: Sending pin request to SVRCore. You may need to run 
systemd-tty-ask-password-agent to provide the password.
[23/Jun/2018:10:58:55.861363768 +0200] - INFO - slapd_extract_cert - SERVER 
CERT NAME: Server-Cert
[23/Jun/2018:10:58:55.874174785 +0200] - INFO - Security Initialization - SSL 
info: Enabling default cipher set.
[23/Jun/2018:10:58:55.887702841 +0200] - INFO - Security Initialization - SSL 
info: Configured NSS Ciphers
[23/Jun/2018:10:58:55.891044528 +0200] - INFO - Security Initialization - SSL 
info: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
[23/Jun/2018:10:58:55.894701167 +0200] - INFO - Security Initialization - SSL 
info: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
[23/Jun/2018:10:58:55.899981889 +0200] - INFO - Security Initialization - SSL 
info: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
[23/Jun/2018:10:58:55.904520090 +0200] - INFO - Security Initialization - SSL 
info: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256: enabled
[23/Jun/2018:10:58:55.907593077 +0200] - INFO - Security Initialization - SSL 
info: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
[23/Jun/2018:10:58:55.911141652 +0200] - INFO - Security Initialization - SSL 
info: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[23/Jun/2018:10:58:55.914589181 +0200] - INFO - Security Initialization - SSL 
info: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
[23/Jun/2018:10:58:55.918208985 +0200] - INFO - Security Initialization - SSL 
info: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[23/Jun/2018:10:58:55.921672628 +0200] - INFO - Security Initialization - SSL 
info: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled
[23/Jun/2018:10:58:55.924819609 +0200] - INFO - Security Initialization - SSL 
info: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
[23/Jun/2018:10:58:55.938295406 +0200] - INFO - Security Initialization - SSL 
info: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[23/Jun/2018:10:58:55.941875247 +0200] - INFO - Security Initialization - SSL 
info: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
[23/Jun/2018:10:58:55.953854096 +0200] - INFO - Security Initialization - SSL 
info: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled
[23/Jun/2018:10:58:55.957446420 +0200] - INFO - Security Initialization - SSL 
info: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
[23/Jun/2018:10:58:55.961207905 +0200] - INFO - Security Initialization - SSL 
info: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[23/Jun/2018:10:58:55.964835089 +0200] - INFO - Security Initialization - SSL 
info: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled
[23/Jun/2018:10:58:55.968648505 +0200] - INFO - Security Initialization - SSL 
info: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
[23/Jun/2018:10:58:55.972318327 +0200] - INFO - Security Initialization - SSL 
info: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled
[23/Jun/2018:10:58:55.976103831 +0200

[Freeipa-users] Re: ipa user-mod --rename failed

[Harald Dunkel via FreeIPA-users]

On 6/22/18 2:09 PM, Harald Dunkel wrote:


I found something new: "ipa-replica-manage list-ruv" shows an error

# ipa-replica-manage list-ruv

unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007


PS: Never mind, that was an old problem. I just forgot.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/2XGTFLKD5HV5SAG4Q7HI7OLQV6LFYFJW/

[Freeipa-users] Re: ipa user-mod --rename failed

[Harald Dunkel via FreeIPA-users]

Hi Thierry,

On 6/21/18 7:19 PM, thierry bordaz via FreeIPA-users wrote:

Hi Harald,

Sorry to be back late.

There is not enough detail to confirm but my feeling is that the MODRDN (write) 
failed to update the changelog because of many replication agreements (read) 
competing with it. It retried several times but without success so the full txn 
was aborted.

I think this can be mitigate with appropriate deadlock policy 
(nsslapd-db-deadlock-policy: 6 for example).

Now it broke the index and that is really unexpected (even after a 
db_deadlock). It worth to try to reproduce.

thanks for your help



I am not sure what that means, but point is that I have a corrupted
entry in 2 of 6 replicas. jxplorer refuses to touch this entry. How
can I fix this?

If the "transaction" was aborted, how comes that the ldap databases
differ? Ain't this the definition for "not having a transaction"?


I found something new: "ipa-replica-manage list-ruv" shows an error

# ipa-replica-manage list-ruv

unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
Replica Update Vectors:
ipa0.example.de:389: 12
ipa2.example.de:389: 5
ipa1.example.de:389: 4
ipa4.example.de:389: 8
ipa3.example.de:389: 6
ipabak.ac.example.de:389: 13
Certificate Server Replica Update Vectors:
ipa0.example.de:389: 1095
ipa2.example.de:389: 97
ipa1.example.de:389: 96
ipabak.ac.example.de:389: 1090

# ipa-replica-manage clean-ruv 7

unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
Replica ID 7 not found



Every helpful hint how to fix this is highly appreciated
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/X5DJ3OMPJGFXPM2XEAEXVYMOC6PFVCQY/

[Freeipa-users] Re: ipa user-mod --rename failed

[Harald Dunkel via FreeIPA-users]

Hi Thierry,

On 6/20/18 6:02 PM, thierry bordaz via FreeIPA-users wrote:
> Hi Harald,
> 
> I wonder if error on ipa1 can not be part of the problem
> 
> [20/Jun/2018:12:16:31.885644563 +0200] - ERR - ldbm_back_modrdn - 
> SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin returned error but did not set 
> SLAPI_RESULT_CODE
> 
> The MODRDN failed, that would explain why 'uid=bobs' remained in the index 
> (and findable via search)
> But this does not explain how RDN and entry itself was changed.
> 
> Could you provide the access logs (ipa1) around that time ?
> 

Sure, see attachment. Hope this helps.


Regards
Harri
[20/Jun/2018:12:16:26.356458986 +0200] conn=2464249 fd=414 slot=414 connection 
from 172.19.96.3 to 172.19.96.3
[20/Jun/2018:12:16:26.357829369 +0200] conn=908087 op=1923845 SRCH 
base="dc=example,dc=de" scope=2 
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/example...@example.de)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/example...@example.de)))"
 attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey 
krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration 
krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange 
krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount 
krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences 
krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock 
passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink 
objectClass"
[20/Jun/2018:12:16:26.358137032 +0200] conn=908087 op=1923845 RESULT err=0 
tag=101 nentries=1 etime=0
[20/Jun/2018:12:16:26.358249074 +0200] conn=908087 op=1923846 SRCH 
base="cn=ipaConfig,cn=etc,dc=example,dc=de" scope=0 filter="(objectClass=*)" 
attrs="ipaConfigString ipaKrbAuthzData ipaUserAuthType"
[20/Jun/2018:12:16:26.358312855 +0200] conn=908087 op=1923846 RESULT err=0 
tag=101 nentries=1 etime=0
[20/Jun/2018:12:16:26.358646683 +0200] conn=908087 op=1923847 SRCH 
base="dc=example,dc=de" scope=2 
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/ipa1.example...@example.de)(krbPrincipalName:caseIgnoreIA5Match:=ldap/ipa1.example...@example.de)))"
 attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey 
krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration 
krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange 
krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount 
krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences 
krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock 
passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink 
objectClass"
[20/Jun/2018:12:16:26.358862079 +0200] conn=908087 op=1923847 RESULT err=0 
tag=101 nentries=1 etime=0
[20/Jun/2018:12:16:26.359061673 +0200] conn=908087 op=1923848 SRCH 
base="cn=EXAMPLE.DE,cn=kerberos,dc=example,dc=de" scope=0 
filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife 
krbMaxRenewableAge krbTicketFlags"
[20/Jun/2018:12:16:26.359116353 +0200] conn=908087 op=1923848 RESULT err=0 
tag=101 nentries=1 etime=0
[20/Jun/2018:12:16:26.359258875 +0200] conn=908087 op=1923849 SRCH 
base="dc=example,dc=de" scope=2 
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ipa1.example...@example.de))"
 attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey 
krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration 
krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange 
krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount 
krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences 
krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock 
passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink 
objectClass"
[20/Jun/2018:12:16:26.35956 +0200] conn=908087 op=1923849 RESULT err=0 
tag=101 nentries=1 etime=0
[20/Jun/2018:12:16:26.359595463 +0200] conn=908087 op=1923850 SRCH 
base="cn=EXAMPLE.DE,cn=kerberos,dc=example,dc=de" scope=0 
filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife 
krbMaxRenewableAge krbTicketFlags"
[20/Jun/2018:12:16:26.359640554 +0200] conn=908087 op=1923850 RESULT err=0 
tag=101 nentries=1 etime=0
[20/Jun/2018:12:16:26.359928111 +0200] conn=908087 op=1923851 SRCH 
base="dc=example,dc=de" scope=2 
filter="(&(objectClass=ipaKrb5DelegationACL)(memberPrincipal=HTTP/ipa1.example...@example.de))"
 attrs="objectClass memberPrincipal"
[20/Jun/2018:12:16:26.360105137 +0200] conn=908087 op=1923851 RESULT err=0 
tag=101 nentries=1 etime=0
[20/Jun/2018:12:16:26.360257657 +0200] conn=908087 op=1923852 SRCH 
base="dc=example,dc=de" scope=2 
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=ad...@example.de))"
 attrs="krbPrin

[Freeipa-users] Re: ipa user-mod --rename failed

[Harald Dunkel via FreeIPA-users]

Hi Thierry,

On 6/20/18 3:31 PM, thierry bordaz via FreeIPA-users wrote:

Hi Harald,

anything noticeable in the error logs when the problem occurred ? (DB_DEADLOCK)



I found something in the slapd error log files on the bad replicas
(attached).

Other replicas show tons of lines like

:
[16/Jun/2018:20:48:14.959827920 +0200] - ERR - DSRetroclPlugin - 
delete_changerecord: could not delete change record 4028228 (rc: 32)
[16/Jun/2018:20:48:14.962389856 +0200] - ERR - DSRetroclPlugin - 
delete_changerecord: could not delete change record 4028229 (rc: 32)
[16/Jun/2018:20:48:14.971465364 +0200] - ERR - DSRetroclPlugin - 
delete_changerecord: could not delete change record 4028230 (rc: 32)
[16/Jun/2018:20:48:14.979659148 +0200] - ERR - DSRetroclPlugin - 
delete_changerecord: could not delete change record 4028231 (rc: 32)
[16/Jun/2018:20:48:14.988140501 +0200] - ERR - DSRetroclPlugin - 
delete_changerecord: could not delete change record 4028232 (rc: 32)
[16/Jun/2018:20:48:14.992190747 +0200] - ERR - DSRetroclPlugin - 
delete_changerecord: could not delete change record 4028233 (rc: 32)
[16/Jun/2018:20:48:15.92668 +0200] - ERR - DSRetroclPlugin - 
delete_changerecord: could not delete change record 4028234 (rc: 32)
[16/Jun/2018:20:48:15.008352154 +0200] - ERR - DSRetroclPlugin - 
delete_changerecord: could not delete change record 4028235 (rc: 32)
:

some of them are months old, but we got "real" problems just today
(at about 12:20).


Any idea?

Regards
Harri
389-Directory/1.3.6.1 B2018.066.1230
ipa1.example.de:636 (/etc/dirsrv/slapd-EXAMPLE-DE)

[10/Jun/2018:05:03:51.329927987 +0200] - INFO - NSMMReplicationPlugin - 
bind_and_check_pwp - agmt="cn=meToipabak.ac.example.de" (ipabak:389): 
Replication bind with GSSAPI auth resumed
[10/Jun/2018:21:52:41.524624603 +0200] - ERR - NSMMReplicationPlugin - 
release_replica - agmt="cn=meToipabak.ac.example.de" (ipabak:389): Unable to 
parse the response  to the endReplication extended operation.
[11/Jun/2018:05:03:15.032390400 +0200] - WARN - NSMMReplicationPlugin - 
acquire_replica - agmt="cn=meToipabak.ac.example.de" (ipabak:389): Unable to 
receive the response for a startReplication extended operation to consumer 
(Can't contact LDAP server). Will retry later.
[11/Jun/2018:15:01:53.402280223 +0200] - ERR - NSMMReplicationPlugin - 
release_replica - agmt="cn=meToipa4.example.de" (ipa4:389): Unable to parse the 
response  to the endReplication extended operation.
[11/Jun/2018:15:10:25.534871480 +0200] - ERR - NSMMReplicationPlugin - 
release_replica - agmt="cn=meToipabak.ac.example.de" (ipabak:389): Unable to 
parse the response  to the endReplication extended operation.
[11/Jun/2018:18:01:14.751312959 +0200] - ERR - NSMMReplicationPlugin - 
repl5_inc_waitfor_async_results  - Timed out waiting for responses: 9443 9444
[12/Jun/2018:05:03:07.042749577 +0200] - ERR - NSMMReplicationPlugin - 
release_replica - agmt="cn=meToipabak.ac.example.de" (ipabak:389): Attempting 
to release replica, but unable to receive endReplication extended operation 
response from the replica. Error -1 (Can't contact LDAP server)
[12/Jun/2018:05:03:53.146431978 +0200] - INFO - NSMMReplicationPlugin - 
bind_and_check_pwp - agmt="cn=meToipabak.ac.example.de" (ipabak:389): 
Replication bind with GSSAPI auth resumed
[13/Jun/2018:05:03:04.991509258 +0200] - ERR - NSMMReplicationPlugin - 
release_replica - agmt="cn=meToipabak.ac.example.de" (ipabak:389): Attempting 
to release replica, but unable to receive endReplication extended operation 
response from the replica. Error -1 (Can't contact LDAP server)
[13/Jun/2018:05:03:39.594946328 +0200] - INFO - NSMMReplicationPlugin - 
bind_and_check_pwp - agmt="cn=meToipabak.ac.example.de" (ipabak:389): 
Replication bind with GSSAPI auth resumed
[14/Jun/2018:00:14:00.113460243 +0200] - ERR - NSMMReplicationPlugin - 
release_replica - agmt="cn=meToipabak.ac.example.de" (ipabak:389): Unable to 
parse the response  to the endReplication extended operation.
[14/Jun/2018:05:03:04.719353837 +0200] - ERR - NSMMReplicationPlugin - 
release_replica - agmt="cn=meToipabak.ac.example.de" (ipabak:389): Attempting 
to release replica, but unable to receive endReplication extended operation 
response from the replica. Error -1 (Can't contact LDAP server)
[14/Jun/2018:05:03:50.105872328 +0200] - INFO - NSMMReplicationPlugin - 
bind_and_check_pwp - agmt="cn=meToipabak.ac.example.de" (ipabak:389): 
Replication bind with GSSAPI auth resumed
[14/Jun/2018:14:40:55.618190503 +0200] - ERR - NSMMReplicationPlugin - 
release_replica - agmt="cn=meToipa4.example.de" (ipa4:389): Unable to parse the 
response  to the endReplication extended operation.
[14/Jun/2018:22:31:04.087866718 +0200] - ERR - NSMMReplicationPlugin - 
release_replica - agmt="cn=meToipa3.example.de" (ipa3:389): Unable to parse the 
response  to the endReplication extended operation.
[15/Jun/2018:05:03:14.032490302 +0200] - WARN - NSMMReplicationPlugin - 
acquire_replica - agmt="cn=meToipabak.a

[Freeipa-users] Re: ipa user-mod --rename failed

[Harald Dunkel via FreeIPA-users]

PS: Running

ipa-replica-manage force-sync --from ipa0.example.de

to sync a "good" replica to a bad one did not help.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/KP4MCAV4SN24JXH6NUSW46BTWX745V2E/

[Freeipa-users] ipa user-mod --rename failed

[Harald Dunkel via FreeIPA-users]

Hi folks,

something got corrupted in my ldap database (again). After running

% ipa user-mod --rename=bobk bobs

I get

% getent passwd bobs
% getent passwd bobk
%

The UID became unusable. (Highly painful, because this user is cut off
from EMails.) This is what I see:

% ipa user-find bobs
--
1 user matched
--
  User login: bobk
  First name: Bob
  Last name: S
  Home directory: /home/bobs
  Login shell: /bin/bash
  Principal alias: b...@example.de
  Email address: b...@example.de
  UID: 1032
  GID: 100
  Account disabled: False

Number of entries returned 1


% ipa user-find bobk
---
0 users matched
---

Number of entries returned 0


% ipa user-find --login bobk
---
0 users matched
---

Number of entries returned 0


% ipa user-find --login bobs
---
0 users matched
---

Number of entries returned 0


Neither login name is found. Using ldap some data is still
available:

% ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=de 
'(uid=bobs)'

dn: uid=bobk,cn=users,cn=accounts,dc=example,dc=de
gecos: Bob S
displayName: Bob S
krbPrincipalName: b...@example.de
mepManagedEntry: cn=bobk,cn=groups,cn=accounts,dc=example,dc=de
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=de
memberOf: cn=projects,cn=groups,cn=accounts,dc=example,dc=de
memberOf: cn=develop,cn=groups,cn=accounts,dc=example,dc=de
uid: bobk
krbLastSuccessfulAuth: 20180607201703Z
krbLoginFailedCount: 0
krbLastFailedAuth: 20180606135524Z
ipaUniqueID: 35292e46-ad70-11e5-8123-0016cc46e69a
givenName: Bob
mail: b...@example.de
homeDirectory: /home/bobs
sn: S
gidNumber: 100
initials: JS
uidNumber: 1032
loginShell: /bin/bash
objectClass: ipaobject
objectClass: person
objectClass: top
objectClass: ipasshuser
objectClass: inetorgperson
objectClass: organizationalperson
objectClass: krbticketpolicyaux
objectClass: krbprincipalaux
objectClass: inetuser
objectClass: posixaccount
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
cn: Bob S
krbLastPwdChange: 20160104091328Z
krbPasswordExpiration: 20400825091328Z
krbExtraData:: AAK4N4pWanNjaHVsdGVAQUlYSUdPLkRFAA==
krbLastAdminUnlock: 20160314150305Z


% ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=de 
'(uid=bobk)'
%

Using jxplorer I see the entry for "bobk" (on 2 replicas), but if I try to
look inside I get an error popup "unable to perform read operation". On the
other 4 replicas I see "bobs" (no problem here).


WTH? How can I cleanup this mess?

Every helpful comment is highly appreciated
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/UB477YJDVHK4242T54KHH65MCZONLCJF/

[Freeipa-users] Re: ipa-replica-manage: unable to decode: {replica 7} 58809c7c000300070000 58809c7c000300070000

[Harald Dunkel via FreeIPA-users]

Hi Ludwig,

On 03/13/18 14:47, Ludwig Krispenz via FreeIPA-users wrote:


On 03/13/2018 09:07 AM, Harald Dunkel via FreeIPA-users wrote:

Hi Ludwig,

On 03/12/18 17:10, Ludwig Krispenz via FreeIPA-users wrote:

Hi,

to get rid of this ruv entry with replicaid 7 you could try to run the 
cleanallruv task directly. On any server (and onöy on one) run

ldapmodify . -D "cn=directory manager"

|dn: cn=clean 7, cn=cleanallruv, cn=tasks, cn=config changetype: add objectclass: 
extensibleObject replica-base-dn:  replica-id: 7 
replica-force-cleaning: yes |

|But I would like to understand how you did get in|to this state, we have seen 
this occasionly, but have no reproducer. Unfortunately the csn for replicaid 7 
is from Jan, 19th 2017 11:01:16 - so you will probably not remember
||


Not sure if its related, but I wrote an EMail to freeipa-users on that day,
reporting an internal error. See

https://www.redhat.com/archives/freeipa-users/2017-January/msg00286.html

the csn of the replicaid 7 is from Jan,19th, two days later. maybe you did ad a 
new replica, or removed one or ...



Got confused by the "17". But maybe the problem was introduced when I
tried to examine or fix the conflict. Just a wild guess.


Looks like you have three problems and I don't think they are related.

1] corrupt RUV element, as Thierry said, we believe to have an an explanation 
how it could occur before a specific fix, and since it is there for one year 
you didn't have that fix. To get rid of this you could apply cleanallruv as I 
suggested in a previous mail, if you do not want to do it, I think it was there 
for quite some time and doesn't do really any harm except raising errors in 
decoding it.



I will try the cleanallruv at the weekend.


2] conflicts, looks like you have conflitcts remaining which are relate to 
managed entries, these are espcially bad and difficult to handle. if you delete 
the conflict of an original entry it will delete the real managed entry and not 
the conflict of the managed entry. And the managed entry plugin is trying to 
prevent you to modify these entries directly.
So what you can do is: determine which entries should be there, then delete 
them or rename them, if managed enty plugin gets in the way, either disable the 
MEP plugin temporarily or modify teh entries by deleting the mep objectclasses 
and attributes, cleanup the conflicts and fix them again



I have the impression that the entry 
"cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de"
has been lost. Is it?

If I got you correctly I have to rename


cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de
to
cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de

Next I have to add

memberOf: cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de
to
dn: cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=de

The entry

dn: 
cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de

can be deleted then. If the mep complains, then I could try to delete
the mepManagedBy entry and add it later again.

Is this correct?


3] Retro Changelog errors:   An error occured while adding change number 
14065299 .
This looks like the retro changelog did mess up the counter to generate the 
next entry. a restart should hopefully reset it and let the RCL continue



The restart did not help, but I could re-initialize ipa1 and ipa4 from
ipa2. They appear to be in sync again, but I would like to make sure
that they *stay* in sync.


Thanx for your support
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa-replica-manage: unable to decode: {replica 7} 58809c7c000300070000 58809c7c000300070000

[Harald Dunkel via FreeIPA-users]

PS: I see tons of error messages like

:
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.819967301 +0100] - ERR - 
DSRetroclPlugin - retrocl_postob - Operation failure [68]
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.824391203 +0100] - ERR - 
DSRetroclPlugin - write_replog_db - An error occured while adding change number 
14065299, dn = changenumber=14065299,cn=changelog: Already exists.
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.827605284 +0100] - ERR - 
DSRetroclPlugin - retrocl_postob - Operation failure [68]
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.831834938 +0100] - ERR - 
DSRetroclPlugin - write_replog_db - An error occured while adding change number 
14065299, dn = changenumber=14065299,cn=changelog: Already exists.
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.834895574 +0100] - ERR - 
DSRetroclPlugin - retrocl_postob - Operation failure [68]
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.839071959 +0100] - ERR - 
DSRetroclPlugin - write_replog_db - An error occured while adding change number 
14065299, dn = changenumber=14065299,cn=changelog: Already exists.
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.842392544 +0100] - ERR - 
DSRetroclPlugin - retrocl_postob - Operation failure [68]
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.846665902 +0100] - ERR - 
DSRetroclPlugin - write_replog_db - An error occured while adding change number 
14065299, dn = changenumber=14065299,cn=changelog: Already exists.
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.850143845 +0100] - ERR - 
DSRetroclPlugin - retrocl_postob - Operation failure [68]
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.854698721 +0100] - ERR - 
DSRetroclPlugin - write_replog_db - An error occured while adding change number 
14065299, dn = changenumber=14065299,cn=changelog: Already exists.
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.858155502 +0100] - ERR - 
DSRetroclPlugin - retrocl_postob - Operation failure [68]
Mar 12 22:38:42 ipa1 ns-slapd: [12/Mar/2018:22:38:42.862632097 +0100] - ERR - 
DSRetroclPlugin - write_replog_db - An error occured while adding change number 
14065299, dn = changenumber=14065299,cn=changelog: Already exists.
:

on ipa1


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa-replica-manage: unable to decode: {replica 7} 58809c7c000300070000 58809c7c000300070000

[Harald Dunkel via FreeIPA-users]

Hi Ludwig,

On 03/12/18 17:10, Ludwig Krispenz via FreeIPA-users wrote:

Hi,

to get rid of this ruv entry with replicaid 7 you could try to run the 
cleanallruv task directly. On any server (and onöy on one) run

ldapmodify . -D "cn=directory manager"

|dn: cn=clean 7, cn=cleanallruv, cn=tasks, cn=config changetype: add objectclass: 
extensibleObject replica-base-dn:  replica-id: 7 
replica-force-cleaning: yes |

|But I would like to understand how you did get in|to this state, we have seen 
this occasionly, but have no reproducer. Unfortunately the csn for replicaid 7 
is from Jan, 19th 2017 11:01:16 - so you will probably not remember
||


Not sure if its related, but I wrote an EMail to freeipa-users on that day,
reporting an internal error. See

https://www.redhat.com/archives/freeipa-users/2017-January/msg00286.html

The conflict is still not resolved completely. There are 2 entries I
could not cleanup, see below. What would you suggest?


[root@ipa1 ~]# ldapsearch -o ldif-wrap=no -x -D "cn=directory manager" -w secret -b 
"dc=example,dc=de" "nsds5ReplConflict=*" \* nsds5ReplConflict
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: nsds5ReplConflict=*
# requesting: * nsds5ReplConflict
#

# ipaservers + 109be302-ccd911e6-a5b3d0c8-d8da17db, hostgroups, accounts, 
example.de
dn: 
cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de
memberOf: 
cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de
mepManagedEntry: cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de
objectClass: top
objectClass: ipahostgroup
objectClass: ipaobject
objectClass: groupOfNames
objectClass: nestedGroup
objectClass: mepOriginEntry
description: IPA server hosts
cn: ipaservers
ipaUniqueID: 14a4041e-ccd9-11e6-b194-fe4936c476ff
nsds5ReplConflict: namingConflict 
cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=de

# ipaservers + 109be304-ccd911e6-a5b3d0c8-d8da17db, ng, alt, example.de
dn: 
cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de
memberHost: 
cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de
objectClass: ipanisnetgroup
objectClass: ipaobject
objectClass: mepManagedEntry
objectClass: ipaAssociation
objectClass: top
nisDomainName: example.de
cn: ipaservers
description: ipaNetgroup ipaservers
mepManagedBy: cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=de
ipaUniqueID: 15699da0-ccd9-11e6-b194-fe4936c476ff
nsds5ReplConflict: namingConflict cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2






[root@ipa1 ~]# ldapsearch -o ldif-wrap=no -x -D "cn=directory manager" -w secret -b 
"cn=hostgroups,cn=accounts,dc=example,dc=de"
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# hostgroups, accounts, example.de
dn: cn=hostgroups,cn=accounts,dc=example,dc=de
objectClass: top
objectClass: nsContainer
cn: hostgroups

# admin_hosts, hostgroups, accounts, example.de
dn: cn=admin_hosts,cn=hostgroups,cn=accounts,dc=example,dc=de
memberOf: 
ipaUniqueID=18c7ac56-c9a3-11e5-a675-00165cee60d7,cn=hbac,dc=example,dc=de
memberOf: cn=admin_hosts,cn=ng,cn=alt,dc=example,dc=de
member: fqdn=srvl023.ac.example.de,cn=computers,cn=accounts,dc=example,dc=de
mepManagedEntry: cn=admin_hosts,cn=ng,cn=alt,dc=example,dc=de
objectClass: ipahostgroup
objectClass: ipaobject
objectClass: nestedGroup
objectClass: groupOfNames
objectClass: top
objectClass: mepOriginEntry
cn: admin_hosts
description: hosts with restricted access
ipaUniqueID: ecc0a97c-c9a3-11e5-bcd9-00165cee60d7

# ipaservers, hostgroups, accounts, example.de
dn: cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=de
memberOf: cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=de
memberOf: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=de
memberOf: cn=Modify Replication 
Agreements,cn=permissions,cn=pbac,dc=example,dc=de
memberOf: cn=Remove Replication 
Agreements,cn=permissions,cn=pbac,dc=example,dc=de
memberOf: cn=Modify DNA Range,cn=permissions,cn=pbac,dc=example,dc=de
memberOf: cn=Read PassSync Managers 
Configuration,cn=permissions,cn=pbac,dc=example,dc=de
memberOf: cn=Modify PassSync Managers 
Configuration,cn=permissions,cn=pbac,dc=example,dc=de
memberOf: cn=Read LDBM Database 
Configuration,cn=permissions,cn=pbac,dc=example,dc=de
memberOf: cn=Add Configuration 
Sub-Entries,cn=permissions,cn=pbac,dc=example,dc=de
memberOf: cn=Read DNA Range,cn=permissions,cn=pbac,dc=example,dc=de
memberOf: cn=Read Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=de
member: fqdn=ipa3.example.de,cn=computers,cn=accounts,dc=example,dc=de
member: fqdn=ipa2.example.de,cn=computers,cn=accounts,dc=example,dc=de
member: fqdn=ipa1.example.de,cn=computers,cn=accounts,dc=example,dc=de
member: fqdn=ipa4.example.de,cn=computers,cn=accounts,dc=example,dc

[Freeipa-users] Re: ipa-replica-manage: unable to decode: {replica 7} 58809c7c000300070000 58809c7c000300070000

[Harald Dunkel via FreeIPA-users]

Hi Thierry,

On 03/12/18 17:52, thierry bordaz via FreeIPA-users wrote:

Hi Harald,

What version of DS are you running ?
We have a reproducer (not systematic) for versions before 
https://bugzilla.redhat.com/show_bug.cgi?id=1516309 but we have not reproduced 
it since then, you may need to upgrade.



I am highly alarmed by this one. Sounds like a fork bomb.
Would you suggest to not run cleanallruv?

Platform is Centos 7.4, directory service was 389-ds-base-\
1.3.6.1-26.el7_4, but this problem might have been introduced
using older version. After the upgrade this morning it is
version 1.3.6.1-28.el7_4.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] ipa-replica-manage: unable to decode: {replica 7} 58809c7c000300070000 58809c7c000300070000

[Harald Dunkel via FreeIPA-users]

Hi folks,

somehow my ipa servers became out of sync. ipa4 has an
additional host entry, not known on the others. On
examining I stumbled over this:


[root@ipa0 ~]# ipa-replica-manage clean-dangling-ruv

unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
These RUVs are dangling and will be removed:
Host: ipabak.ac.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa1.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa0.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa3.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa4.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa2.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Proceed with cleaning? [no]: yes
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
Clean the Replication Update Vector for ipabak.ac.example.de:389
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
Cleanup task created

[root@ipa0 ~]# ipa-replica-manage clean-dangling-ruv

unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
No dangling RUVs found

[root@ipa0 ~]# ipa-replica-manage list-ruv

unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
Replica Update Vectors:
ipa0.example.de:389: 12
ipa2.example.de:389: 5
ipa1.example.de:389: 4
ipa4.example.de:389: 8
ipa3.example.de:389: 6
ipabak.ac.example.de:389: 13
Certificate Server Replica Update Vectors:
ipa0.example.de:389: 1095
ipa2.example.de:389: 97
ipa1.example.de:389: 96
ipabak.ac.example.de:389: 1090

The ruvs are the same on all 6 hosts (AFAICS), so I wonder how I could
fix this?


Every helpful comment is highly appreciated.
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: how to avoid ntpd?

[Harald Dunkel via FreeIPA-users]

On 01/15/2018 09:04 PM, Rob Crittenden via FreeIPA-users wrote:


That's fine but it doesn't address the original problem: he doesn't want
anything managing the clock on his system at all:

"some ipa servers in my environment are not permitted to change
the clock."



These are LXC containers without the appropriate capabilities to
change the clock or to access other hardware. The clock *is* in
sync, but this is out of reach for freeipa.

Probably you agree that running ntpd is not sufficient for Kerberos.
You have to watch it using ntpq -p to verify that it is connected to
some peers and that the time is actually in sync with these peers.

I don't see any reason why ipactl refuses to start the other services,
if ntpd failed to start. There is no indication that the clock is
*not* in sync within Kerberos' thresholds.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ERR - attrlist_replace - attr_replace

[Harald Dunkel via FreeIPA-users]

On 01/15/2018 09:47 AM, Ludwig Krispenz via FreeIPA-users wrote:

Hi Harri,

the suffix object maintains a list of referrals to be returned if the server is 
in read only mode. It is updated based on the supplier ruv and only uses the 
url. If a ruv contains the same url for different replica ids these errors are 
logged. It should be fixed in 1.3.6 now, see: 
https://bugzilla.redhat.com/show_bug.cgi?id=1499668



Its gone with the new version.

Thanx for your help
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] how to avoid ntpd?

[Harald Dunkel via FreeIPA-users]

Hi folks,

some ipa servers in my environment are not permitted to change
the clock. If I use "systemctl mask ntpd" to avoid the "degraded"
returned by "systemctl status", then ipactl fails without the
ntpd service:

# ipactl restart
Stopping pki-tomcatd Service
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting httpd Service
Restarting ipa-custodia Service
Restarting pki-tomcatd Service
Restarting ipa-otpd Service
Starting ntpd Service
Failed to start ntpd Service
Shutting down
Hint: You can use --ignore-service-failure option for forced start in case that 
a non-critical service failed
Aborting ipactl

If I unmask ntpd, then systemctl status returns "degrarded" again,
but ipa is fine.

The option "--ignore-service-failures" ignores *all* service
failures. I wonder how I can tell freeipa to ignore ntpd and
rely upon sysvinit or systemd to start it, if necessary?


Every helpful comment is highly appreciated.
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] ERR - attrlist_replace - attr_replace

[Harald Dunkel via FreeIPA-users]

Hi folks,

/var/log/messages includes tons of error messages like

Jan 15 07:34:56 ipa1 ns-slapd: [15/Jan/2018:07:34:56.684472891 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa3.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:34:58 ipa1 ns-slapd: [15/Jan/2018:07:34:58.421020416 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa3.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:34:58 ipa1 ns-slapd: [15/Jan/2018:07:34:58.431938703 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa3.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:34:58 ipa1 ns-slapd: [15/Jan/2018:07:34:58.444161918 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa3.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:34:59 ipa1 ns-slapd: [15/Jan/2018:07:34:59.00395 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa2.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:34:59 ipa1 ns-slapd: [15/Jan/2018:07:34:59.010930343 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa2.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:34:59 ipa1 ns-slapd: [15/Jan/2018:07:34:59.014371119 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa2.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:35:00 ipa1 ns-slapd: [15/Jan/2018:07:35:00.078732745 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa2.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:35:00 ipa1 ns-slapd: [15/Jan/2018:07:35:00.085465505 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa2.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:35:00 ipa1 ns-slapd: [15/Jan/2018:07:35:00.088906212 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa2.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:35:00 ipa1 ns-slapd: [15/Jan/2018:07:35:00.259716279 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa4.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:35:00 ipa1 ns-slapd: [15/Jan/2018:07:35:00.270409631 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa4.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.
Jan 15 07:35:00 ipa1 ns-slapd: [15/Jan/2018:07:35:00.273799363 +0100] - ERR - 
attrlist_replace - attr_replace (nsslapd-referral, 
ldap://ipa4.example.de:389/dc%3Dexample%2Cdc%3Dde) failed.

I already found https://access.redhat.com/solutions/2741521, cleaned up
the "dangling RUVs" and rebootet the servers.

What is ns-slapd trying to tell me?


Every helpful comment is highly appreciated
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

[Harald Dunkel via FreeIPA-users]

On 12/14/17 17:09, Harald Dunkel via FreeIPA-users wrote:

Hi Flo, Rob,

On 12/14/17 9:27 AM, Florence Blanc-Renaud via FreeIPA-users wrote:


The files should contain multiple certificates (IPA CA and the external CA 
certificates). If it is not the case, please check first if there were AVC 
issues (if running in SElinux enforcing mode), and feel free to file a bug.



You are right, its a set of certificates.



Maybe a related problem: ldapmodify gives me

% ldapmodify -ZZ -D "cn=directory manager" -W -a
ldap_start_tls: Operations error (1)
additional info: SSL connection already established.

???

Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

[Harald Dunkel via FreeIPA-users]

Hi Flo, Rob,

On 12/14/17 9:27 AM, Florence Blanc-Renaud via FreeIPA-users wrote:


The files should contain multiple certificates (IPA CA and the external CA 
certificates). If it is not the case, please check first if there were AVC 
issues (if running in SElinux enforcing mode), and feel free to file a bug.



You are right, its a set of certificates.

One last question: Is it safe to drop the old root CA from the
certutil database? Its no longer in LDAP, anyway. "getcert list"
doesn't mention any certificates derived from the old PKI, either.


I highly appreciate your support and patience

Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

[Harald Dunkel via FreeIPA-users]

Hi Flo,

On 12/12/17 3:59 PM, Harald Dunkel via FreeIPA-users wrote:


My concern is, it looks much more restricted than the old root CA
cerificate:

# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias

Certificate Nickname Trust Attributes
  SSL,S/MIME,JAR/XPI

Server-Cert cert-pki-ca  u,u,u
subsystemCert cert-pki-ca    u,u,u
caSigningCert cert-pki-ca    CTu,Cu,Cu
auditSigningCert cert-pki-ca u,u,Pu
ocspSigningCert cert-pki-ca  u,u,u
CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C
CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE  C,,

Shouldn't it be "CT,C,C" as well?


:
:


ipa-cert-update said

# ipa-certupdate
trying https://ipa1.example.de/ipa/json
[try 1]: Forwarding 'schema' to json server 'https://ipa1.example.de/ipa/json'
trying https://ipa1.example.de/ipa/json
[try 1]: Forwarding 'ca_is_enabled' to json server 
'https://ipa1.example.de/ipa/json'
[try 1]: Forwarding 'ca_find/1' to json server 
'https://ipa1.example.de/ipa/json'
Systemwide CA database updated.
Systemwide CA database updated.
The ipa-certupdate command was successful

dmesg shows that there was a core dump:

[108604.869633] ns-slapd[23051]: segfault at 10 ip 7fb60841dc30 sp 
7fb60af56c88 error 4 in libpthread-2.17.so[7fb608414000+17000]

Problem: The certificate in /etc/ipa/ca.crt and /usr/share/ipa/html/\
ca.crt is still old. The files have been touched, but not replaced
by the new certificate.



AFAICT this is not as documented. Would you suggest to file a bug
report?


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

[Harald Dunkel via FreeIPA-users]

Hi Flo,

On 12/12/17 2:50 PM, Florence Blanc-Renaud via FreeIPA-users wrote:

On 12/10/2017 10:58 AM, Harald Dunkel via FreeIPA-users wrote:

Hi Flo,

On 12/08/17 15:36, Florence Blanc-Renaud via FreeIPA-users wrote:

Hi,

I would try to remove the new root CA from LDAP and re-import it using 
ipa-cacert-manage install -t C,,
This should create the entry with the appropriate attributes.

Flo

Result: The new root CA certificate shows much better attributes in ldap:

dn: cn=CN\3Droot-CA\2COU\3Dexample Certificate Authority\2CO\3Dexample 
AG\2CC\3DDE,cn=certificates,cn=ipa,cn=etc,dc=example,dc=de
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
cn: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
ipaCertSubject: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE
ipaPublicKey:: MIICIjAN...
cACertificate;binary:: MIIGDTCC...
ipaKeyTrust: trusted
ipaCertIssuerSerial: CN=root-CA,OU=example Certificate Authority,O=example 
AG,C=DE;1


A lot of ipaKeyExtUsage attributes appear to be missing, though, compared to the
old root CA certificate. Is this expected?


The ipaKeyExtUsage attribute is built from the trust flags provided to 
ipa-cacert-manage install, so it looks normal for me.



My concern is, it looks much more restricted than the old root CA
cerificate:

# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

Server-Cert cert-pki-ca  u,u,u
subsystemCert cert-pki-cau,u,u
caSigningCert cert-pki-caCTu,Cu,Cu
auditSigningCert cert-pki-ca u,u,Pu
ocspSigningCert cert-pki-ca  u,u,u
CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C
CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE  C,,

Shouldn't it be "CT,C,C" as well?




ipa-certupdate needs to be run with a kerberos ticket. Did you run kinit admin 
before launching the command, and is your ticket still valid (klist will 
provide the expiration date)?



Nope, that was the problem. I was just looking for the certificate,
ignoring Kerberos.

ipa-cert-update said

# ipa-certupdate
trying https://ipa1.example.de/ipa/json
[try 1]: Forwarding 'schema' to json server 'https://ipa1.example.de/ipa/json'
trying https://ipa1.example.de/ipa/json
[try 1]: Forwarding 'ca_is_enabled' to json server 
'https://ipa1.example.de/ipa/json'
[try 1]: Forwarding 'ca_find/1' to json server 
'https://ipa1.example.de/ipa/json'
Systemwide CA database updated.
Systemwide CA database updated.
The ipa-certupdate command was successful

dmesg shows that there was a core dump:

[108604.869633] ns-slapd[23051]: segfault at 10 ip 7fb60841dc30 sp 
7fb60af56c88 error 4 in libpthread-2.17.so[7fb608414000+17000]

Problem: The certificate in /etc/ipa/ca.crt and /usr/share/ipa/html/\
ca.crt is still old. The files have been touched, but not replaced
by the new certificate.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

[Harald Dunkel via FreeIPA-users]

Hi folks,

any ideas about how to proceed? Is this bbr? Do I have to reactivate
the old pki to get out of this mess?


Every helpful comment is highly appreciated.
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

[Harald Dunkel via FreeIPA-users]

Hi Flo,

On 12/08/17 15:36, Florence Blanc-Renaud via FreeIPA-users wrote:
> Hi,
>
> I would try to remove the new root CA from LDAP and re-import it using 
> ipa-cacert-manage install -t C,,
> This should create the entry with the appropriate attributes.
>
> Flo
Result: The new root CA certificate shows much better attributes in ldap:

dn: cn=CN\3Droot-CA\2COU\3Dexample Certificate Authority\2CO\3Dexample 
AG\2CC\3DDE,cn=certificates,cn=ipa,cn=etc,dc=example,dc=de
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
cn: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
ipaCertSubject: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE
ipaPublicKey:: MIICIjAN...
cACertificate;binary:: MIIGDTCC...
ipaKeyTrust: trusted
ipaCertIssuerSerial: CN=root-CA,OU=example Certificate Authority,O=example 
AG,C=DE;1


A lot of ipaKeyExtUsage attributes appear to be missing, though, compared to the
old root CA certificate. Is this expected?

ipa-certupdate failed:

# ipa-certupdate -v
ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: Not logging to a file
ipa: DEBUG: Loading Index file from 
'/var/lib/ipa-client/sysrestore/sysrestore.index'
ipa.ipaclient.plugins.rpcclient.rpcclient: INFO: trying 
https://ipa1.example.de/ipa/json
ipa.ipaclient.plugins.rpcclient.rpcclient: DEBUG: Created connection 
context.rpcclient_54790992
ipa.ipaclient.plugins.rpcclient.rpcclient: INFO: [try 1]: Forwarding 'schema' 
to json server 'https://ipa1.example.de/ipa/json'
ipa: DEBUG: New HTTP connection (ipa1.example.de)
ipa: DEBUG: HTTP connection destroyed (ipa1.example.de)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in 
single_request
self.get_auth_info()
  File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in 
get_auth_info
self._handle_exception(e, service=service)
  File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 578, in 
_handle_exception
raise errors.TicketExpired()
TicketExpired: Ticket expired
ipa.ipaclient.plugins.rpcclient.rpcclient: DEBUG: Destroyed connection 
context.rpcclient_54790992
ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG:   File 
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute
return_value = self.run()
  File "/usr/lib/python2.7/site-packages/ipaclient/install/ipa_certupdate.py", 
line 57, in run
api.finalize()
  File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 714, in 
finalize
self.__do_if_not_done('load_plugins')
  File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 421, in 
__do_if_not_done
getattr(self, name)()
  File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 592, in 
load_plugins
for package in self.packages:
  File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 948, in 
packages
ipaclient.remote_plugins.get_package(self),
  File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", 
line 126, in get_package
plugins = schema.get_package(server_info, client)
  File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", 
line 534, in get_package
schema = Schema(client)
  File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", 
line 385, in __init__
fingerprint, ttl = self._fetch(client, ignore_cache=read_failed)
  File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", 
line 409, in _fetch
schema = client.forward(u'schema', **kwargs)['result']
  File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1116, in forward
return self._call_command(command, params)
  File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1092, in 
_call_command
return command(*params)
  File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1246, in _call
return self.__request(name, args)
  File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1213, in __request
verbose=self.__verbose >= 3,
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in 
single_request
self.get_auth_info()
  File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in 
get_auth_info
self._handle_exception(e, service=service)
  File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 578, in 
_handle_exception
raise errors.TicketExpired()

ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: The ipa-certupdate 
command failed, exception: TicketExpired: Ticket expired
ipa.ipaclient.install.ipa_certupdate.CertUpdate: ERROR: Ticket expired
ipa.ipaclient.install.ipa_certupdate.CertUpdate: ERROR: The ipa-certupdate 
command failed.


Restarting ipa did not help. ???

Regards
Harri



signature.asc
Description: OpenPGP digital signature
__

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

[Harald Dunkel via FreeIPA-users]

Hi Flo,

On 12/8/17 10:52 AM, Florence Blanc-Renaud wrote:


Hi Harald,

the external CAs and FreeIPA CA must be stored in the LDAP server 
(cn=certificates,cn=ipa,cn=etc,$BASEDN). The correct procedure to add external 
CAs to the LDAP server is to run ipa-cacert-manage install.


ACK


You need first to have a clean state in the LDAP server. When all the required 
CAs are stored in LDAP with the right trust attribute, you can use 
ipa-certupdate to retrieve them and place them in the NSS databases and 
/etc/ipa/ca.crt.



The ipa Servers ipa1 and ipa2 are in sync, as reported by ipa-replica-manage
and ipa-csreplica-manage.

jxplorer shows me 3 certificates:

- the ipa ca certificate signed by the new root CA
- the old root CA certificate "cn=example Root CA, ..."
- the new root CA certificate "cn=root-CA, ..."

The old root CA certificate has much more attributes set than the
new one, esp. there is an attribute ipaKeyTrust set to "trusted",
and several other ipaKeyExtUsage attributes not set for the new
root CA certificate. Attached you can find the output of ldapsearch
for cn=certificates.

As you suggested, I used ipa-certupdate to deploy the new PKI, but
I wonder if the attributes for the new root CA certificate are set
correctly? Please note the "ipaKeyExtUsage: 1.3.6.1.4.1.3319.6.10.16"
set only for the new root CA cert.

Looking into the old and new root CA certs I see very similar x509v3
extensions. Do you think the new root certificate could be bad
internally?


If some certificates are manually added to the NSS databases but not present in 
the LDAP server, the next call to ipa-certupdate will remove them, this is why 
the state is not persistent.



I highly appreciate this central location.


If you want to completely remove an old root CA, you need to delete it from the 
LDAP server otherwise it will return on next call to ipa-certupdate.



AFAIU it is necessary to fix the attributes of the new root CA
certificate entry in LDAP first. Would you recommend to set the
lost ipaKeyExtUsage attributes?


Regards
Harri
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# certificates, ipa, etc, example.de
dn: cn=certificates,cn=ipa,cn=etc,dc=example,dc=de
objectClass: nsContainer
objectClass: top
cn: certificates

# CN\3Dexample Root CA\2COU\3Dexample Certificate Authority\2CO\3Dexample 
AG\2CC\3DDE, certificates, ipa, etc, example.de
dn: cn=CN\3Dexample Root CA\2COU\3Dexample Certificate Authority\2CO\3Dexample 
AG\2CC\3DDE,cn=certificates,cn=ipa,cn=etc,dc=example,dc=de
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.2
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.3
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.4
cn: CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
ipaCertSubject: CN=example Root CA,OU=example Certificate Authority,O=example 
AG,C=DE
ipaPublicKey:: MIICIjAN...
cACertificate;binary:: MIIGGzCC...
ipaKeyTrust: trusted
ipaCertIssuerSerial: CN=example Root CA,OU=example Certificate 
Authority,O=example AG,C=DE;1

# EXAMPLE.DE IPA CA, certificates, ipa, etc, example.de
dn: cn=EXAMPLE.DE IPA CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=de
ipaConfigString: ipaCa
ipaCertSubject: CN=Certificate Authority,O=example AG,C=DE
ipaKeyTrust: trusted
cACertificate;binary:: MIIE9DCC...
ipaPublicKey:: MIIBIjAN...
ipaCertIssuerSerial: CN=root-CA,OU=example Certificate Authority,O=example 
AG,C=DE;4
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
cn: EXAMPLE.DE IPA CA
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.2
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.3
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.4
ipaKeyExtUsage: 1.3.6.1.5.2.3.5
ipaKeyExtUsage: 1.3.6.1.5.2.3.4

# CN\3Droot-CA\2COU\3Dexample Certificate Authority\2CO\3Dexample AG\2CC\3DDE, 
certificates, ipa, etc, example.de
dn: cn=CN\3Droot-CA\2COU\3Dexample Certificate Authority\2CO\3Dexample 
AG\2CC\3DDE,cn=certificates,cn=ipa,cn=etc,dc=example,dc=de
ipaKeyExtUsage: 1.3.6.1.4.1.3319.6.10.16
cn: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
ipaCertSubject: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE
ipaPublicKey:: MIICIjAN...
cACertificate;binary:: MIIGDTCC...
ipaCertIssuerSerial: CN=root-CA,OU=example Certificate Authority,O=example 
AG,C=DE;1

# search result
search: 2
result: 0 Success

# numResponses: 5
# numEntries: 4
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org