[Freeipa-users] Fedora 40: new warning in ipa-healthckeck

[Jochen Kellner via FreeIPA-users]

Hi,

I've upgraded my freeipa server to Fedora 40 (the system was installed
several releases ago). After the upgrade I get the following new warning
from ipa-healthcheck:

  {
"source": "ipahealthcheck.ds.backends",
"check": "BackendsCheck",
"result": "WARNING",
"uuid": "875db8e3-029c-46f7-87e5-bf9a216d9637",
"when": "20240426184431Z",
"duration": "0.031642",
"kw": {
  "key": "DSBLE0005",
  "items": [
"nsslapd-dbcachesize",
"nsslapd-db-logdirectory",
"nsslapd-db-transaction-wait",
"nsslapd-db-checkpoint-interval",
"nsslapd-db-compactdb-interval",
"nsslapd-db-compactdb-time",
"nsslapd-db-transaction-batch-val",
"nsslapd-db-transaction-batch-min-wait",
"nsslapd-db-transaction-batch-max-wait",
"nsslapd-db-logbuf-size",
"nsslapd-db-page-size",
"nsslapd-db-locks",
"nsslapd-db-locks-monitoring-enabled",
"nsslapd-db-locks-monitoring-threshold",
"nsslapd-db-locks-monitoring-pause",
"nsslapd-db-private-import-mem",
"nsslapd-db-deadlock-policy"
  ],
  "msg": "Found configuration attributes that are not applicable for the 
configured backend type."
}
  },

According to
https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html the
bdb backend is deprecated. The system was installed with
389-ds-base < 1.4.4.9-1.fc33.x86_64 (I see the upgrade to that version
in /var/log/dnf.rpm.log*. Since 3.0 new installations should use LMBD as
the backend. Is that true for new installations?

What is the desired action that I should take?

I can remove the options from the dirsrv configuration. Should I?

Shall I switch to lmdb manually? Or is that something that
ipa-server-upgrade should be doing?

Otherwise I can suppress the message in ipa-healthcheck for now. But I
guess I should fix my installation before the deprecated support really
gets dropped... Is deploying a new replica and decommisioning the old
server we the preferred action?

Jochen

-- 
This space is intentionally left blank.
--
___
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: Issues with sudo permissions

[Jochen Kellner via FreeIPA-users]

slek kus via FreeIPA-users 
writes:

> Hi Jochen, nsswitch.conf checks local files and sss. Below is the contents of 
> etc/pam.d/sudo:

> sssd_[domain].log:
> https://privatebin.net/?e841ce0e62791e1b#CU9EhpDrajzQXEihhp2jmjbD92RtG8YZ6Sw4FxaZw1Zx

I think that sssd is ok here. I didn't verify the RBAC rule in detail,
but ALLOWED looks ok for me.

Did you have a look at
https://docs.pagure.org/sssd.sssd/users/sudo_troubleshooting.html ?

Verify the sssd.conf file as described at the start of the page and then
produce debug logs:

How do I get sudo logs?

Open /etc/sudo.conf and put down the following lines:

Debug sudo /var/log/sudo_debug all@debug
Debug sudoers.so /var/log/sudo_debug all@debug

Run sudo

File /var/log/sudo_debug contains sudo logs

My current guess is that sudo is at fault here - take a look at the
debug log.

Jochen

-- 
This space is intentionally left blank.
--
___
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: Issues with sudo permissions

[Jochen Kellner via FreeIPA-users]

slek kus via FreeIPA-users 
writes:

> Hi Rob, unfortunally not. I am honestly out of options here. I must be
> missing something trivial or it is a configuration issue.
...
> On the client:
>
> 
> ansible@debclient1:~$ sudo -i
> [sudo] password for ansible: 
> ansible is not allowed to run sudo on debclient1.
> 

Let's see how the client is configured and what's in the logs.

- /etc/nsswitch.conf should have this line:
sudoers: files sss

- What's in /etc/pam.d/sudo* ?

- What says "sudo -l"?

- something useful in /var/log/sssd/sssd_.log and /var/log/auth.log?

Troubleshooting docs are here: 
https://docs.pagure.org/sssd.sssd/users/sudo_troubleshooting.html

Jochen

-- 
This space is intentionally left blank.
--
___
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.

[Jochen Kellner via FreeIPA-users]

Alexander Bokovoy via FreeIPA-users
 writes:

> As discussions on this mailing list show, there are plenty of edge
> cases, mostly around 'legacy' UID/GIDs and missing ID ranges that would
> have covered those IDs. Or ID ranges missing SID-specific attributes
> (base RID and secondary base RID) that prevent use of those ranges to
> generate SIDs. 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.

Would it be helpful to have ipa-healthcheck or checkipaconsistency warn
about that? During ipa-server-upgrade is too late and it runs most of
the time in the background...

Jochen "I also needed to fix my id ranges"
-- 
This space is intentionally left blank.
--
___
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: Health check issues

[Jochen Kellner via FreeIPA-users]

Alex Corcoles via FreeIPA-users 
writes:

> Hi all,
>
> Sorry I didn't keep track of this more accurately. Some time ago, the
> ipa-healthcheck service started failing (September 23rd, I think). I
> took a look, and IIRC, it said something like some certs were about to
> expire. I ignored that (because they renew automatically?). But then I
> checked some time after that, and ipa-healthcheck started reporting:
...
>   "msg": "Certificate 'auditSigningCert cert-pki-ca' does not match the 
> value of ca.audit_signing.cert in /etc/pki/pki-tomcat/ca/CS.cfg"
...
> Any thoughts?

This looks similar to
https://pagure.io/freeipa/issue/9277
https://github.com/dogtagpki/pki/issues/2157

I've used this play to fix my system:
---
# file: freeipa-fixes.yml
- name: Fix problems in IPA installations or configurations after install / 
postinstall or later
  hosts:
  - ipaservers
  become: true

  tasks:
# ...
  # Another healthcheck fix: when the PKI server certificate is renewed
  # the new certificate is written to /var/lib/pki/pki-tomcat/ca/conf/CS.cfg.
  # It needs to be in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg too.
  # {
  #   "source": "pki.server.healthcheck.meta.csconfig",
  #   "check": "KRADogtagCertsConfigCheck",
  #   "result": "ERROR",
  #   "uuid": "892ad5b7-8612-4476-8120-2a5fe6c6b005",
  #   "when": "20221116030029Z",
  #   "duration": "0.024925",
  #   "kw": {
  # "key": "kra_sslserver",
  # "nickname": "Server-Cert cert-pki-ca",
  # "directive": "kra.sslserver.cert",
  # "configfile": "/var/lib/pki/pki-tomcat/kra/conf/CS.cfg",
  # "msg": "Certificate 'Server-Cert cert-pki-ca' does not match the value
  #  of kra.sslserver.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg"
  #   }
  # },
  # This is likely a bug in /usr/libexec/ipa/certmonger/renew_ca_cert
  - name: Fetch ca.sslserver.cert from /var/lib/pki/pki-tomcat/ca/conf/CS.cfg
ansible.builtin.command:
  cmd: awk -F '=' '/^ca.sslserver.cert=/ { print $2 }' 
/var/lib/pki/pki-tomcat/ca/conf/CS.cfg
register: ca_sslserver_cert
check_mode: false
changed_when: false

  - name: Fetch kra.sslserver.cert= from /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
ansible.builtin.command:
  cmd: awk -F '=' '/^kra.sslserver.cert=/ { print $2 }' 
/var/lib/pki/pki-tomcat/kra/conf/CS.cfg
register: kra_sslserver_cert
check_mode: false
changed_when: false

#  - name: debug display the possibly different certs
#ansible.builtin.debug:
#  var: "{{ item }}"
#loop:
#- ca_sslserver_cert.stdout
#- kra_sslserver_cert.stdout

  - name: Fix ipa-healthcheck, KRADogtagCertsConfigCheck
ansible.builtin.lineinfile:
  dest: /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
  regexp: '^kra.sslserver.cert='
  line: 'kra.sslserver.cert={{ ca_sslserver_cert.stdout }}'
  owner: pkiuser
  group: pkiuser
  mode: '0660'
  backup: true
when: ca_sslserver_cert.stdout != kra_sslserver_cert.stdout
notify: Restart pki-tomcat

#  "key": "transportCert cert-pki-kra",
# "directive": "ca.connector.KRA.transportCert",
# "configfile": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg",
# "msg": "Certificate 'transportCert cert-pki-kra' does not match the value 
of
#  ca.connector.KRA.transportCert in /var/lib/pki/pki-tomcat/c 
onf/ca/CS.cfg"
  - name: Fetch Certificate 'transportCert cert-pki-kra'
ansible.builtin.shell:
  cmd: certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'transportCert 
cert-pki-kra' -a | awk '/^[^-]/ { sub(/\r/, ""); printf("%s", $0) }'
register: transportcert
check_mode: false
changed_when: false

  - name: Fetch Certificate ca.connector.KRA.transportCert
ansible.builtin.shell:
  cmd: awk -F '=' '/^ca.connector.KRA.transportCert=/ { print $2 }' 
/var/lib/pki/pki-tomcat/ca/conf/CS.cfg
register: ca_connector_transportcert
check_mode: false
changed_when: false

  - name: Fix ipa-healthcheck, ca.connector.KRA.transportCert
ansible.builtin.lineinfile:
  dest: /var/lib/pki/pki-tomcat/ca/conf/CS.cfg
  regexp: '^ca.connector.KRA.transportCert='
  line: 'ca.connector.KRA.transportCert={{ transportcert.stdout }}'
  owner: pkiuser
  group: pkiuser
  mode: '0660'
  backup: true
when: ca_connector_transportcert.stdout != transportcert.stdout
notify: Restart pki-tomcat

  - name: Fetch Certificate kra.transport.cert
ansible.builtin.shell:
  cmd: awk -F '=' '/^kra.transport.cert=/ { print $2 }' 
/var/lib/pki/pki-tomcat/kra/conf/CS.cfg
register: kra_transport_cert
check_mode: false
changed_when: false

  - name: Fix ipa-healthcheck, kra.transport.cert
ansible.builtin.lineinfile:
  dest: /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
  regexp: '^kra.transport.cert='
  line: 'kra.transport.cert={{ transportcert.stdout }}'
  owner: pkiuser
  group: pkiuser
  mode: '0660'
  backup: true
when: kra_transport_cert.stdout != transportcert.stdout
notify: Restart 

[Freeipa-users] Re: RedHat and 2FA Problem

[Jochen Kellner via FreeIPA-users]

Sam Morris via FreeIPA-users 
writes:

> On 21/09/2023 08:55, Sirio Sannipoli via FreeIPA-users wrote:
>> Thanks so much Sumit,
>> your suggestion works perfectly.
>> I'm still curious about the difference in behavior between
>> distributions, but it's not that important.
>> Greetings
>
> Probably on RHEL you have pam_sssd in your PAM stack, which is able to
> present separate prompts for both factors; whereas on Debian you have
> pam_unix which can only present a "Password:" prompt.
>
> This happens because pam_unix is registered in Debian's
> pam-auth-update mechanism with priority 256, whereas pam_sss is only
> registred with priority 128. Thus, the 'common-auth' PAM stack (which
> is included by sshd, login, gdm, etc) has pam_auth.so first, which
> prompts for the password; then pam_sss.so is called, with the
> 'use_first_pass' option, so it uses the password stashed by
> pam_unix.so instead of presenting its own prompts.
>
> I think pam_sss's priority should be bumped but I've not gotten around
> to chasing this request:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001644

Thanks for opening the bug - I think that's the right thing to do.
As a workaround I prepare a file /usr/share/pam-configs/unix+sss with
the config I wanted and enable that instead of "unix" in
pam-auth-update.

Jochen

-- 
This space is intentionally left blank.
___
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: Multiple http services on one host

[Jochen Kellner via FreeIPA-users]

Anonymous  via FreeIPA-users 
writes:

> I want to authenticate to cockpit with kerberos. Some of the servers
> however have other services running on the http service in
> freeipa. Freeipa is also an example. What is the proper way that I can
> have kerberos authentication on cockpit running on freeipa master and
> replica servers? I know that I can create a service called
> cockpit/master.domain.com but from what I've been told, or at least
> I've understood for kerberos to function the service needs to be
> HTTP/master.domain.com

The cockpit documentation details what need to be done:
https://cockpit-project.org/guide/latest/sso.html

I do use the followinf ansible-play to install and configure cockpit.

---
# Maybe this can be used?
# https://github.com/linux-system-roles/cockpit
- name: Install, enable, and configure cockpit on a host
  hosts: cockpit
  become: true

  vars:
keytab: /etc/cockpit/krb5.keytab

  tasks:
  - name: Install cockpit packages
ansible.builtin.package:
  name:
  - cockpit
  state: present

  - name: Install cockpit-machines packages on KVM hosts
ansible.builtin.package:
  name:
  - cockpit-machines
  state: present
when: "'kvm' in group_names"

  - name: Remove cockpit-machines packages on non-KVM hosts
ansible.builtin.package:
  name:
  - cockpit-machines
  state: absent
when: "'kvm' not in group_names"

  - name: Ensure that cockpit.socket is started
ansible.builtin.systemd:
  state: started
  enabled: true
  name: cockpit.socket

  - name: Ensure the cockpit port 9090 is accessible
ansible.posix.firewalld:
  service: cockpit
  permanent: true
  immediate: true
  state: enabled
when: ansible_os_family == "RedHat"

# On Debian our user needs urllib-gssapi (via pip3)
# Fedora has a package for that
  - name: Install urllib-gssapi python package on Debian
ansible.builtin.pip:
  name: urllib-gssapi
when: ansible_os_family == 'Debian'

  - name: Install urllib-gssapi python package on RedHat systems
ansible.builtin.package:
  name:
  - python3-urllib-gssapi
  state: present
when: ansible_os_family == 'RedHat'


  - name: Ensure kerberos service principal for cockpit is present
community.general.ipa_service:
  name: "{{ item }}"
  state: present
environment:
  KRB5_CLIENT_KTNAME: /etc/krb5.keytab
with_items:
- "cockpit/{{ inventory_hostname }}@JOCHEN.ORG"

  - name: Ensure kerberos service principal for HTTP is present
freeipa.ansible_freeipa.ipaservice:
  name: "{{ item }}"
  state: present
  ok_as_delegate: true
  ok_to_auth_as_delegate: true
  ipaadmin_principal: "host/{{ inventory_hostname }}@JOCHEN.ORG"
environment:
  KRB5_CLIENT_KTNAME: /etc/krb5.keytab
with_items:
- "HTTP/{{ inventory_hostname }}@JOCHEN.ORG"

  # With this heuristic we try to find a suitable keytab to copy.
  # Another approach might be tr retrieve the keytab (needing
  # special permissions).
  - name: Looking for a suitable keytab for cockpit
ansible.builtin.shell:
  cmd: |
for i in /etc/apache2/http.keytab /etc/keycloak/keycloak.keytab 
/var/lib/ipa/gssproxy/http.keytab; do
  if [ -f $i ]; then echo "$i"; exit; fi
done
changed_when: false
check_mode: false
register: _found_file

  - name: Debug
ansible.builtin.debug:
  var: _found_file

  - name: Get the keytab, we don't have one
ansible.builtin.command:
  argv:
  - /usr/sbin/ipa-getkeytab
  - -k
  - "{{ keytab }}"
  - -p
  - 'HTTP/{{ inventory_hostname }}@JOCHEN.ORG'
  creates: "{{ keytab }}"
register: ipagetkeytab
# Do not fail on error codes 3 and 5:
#   3 - Unable to open keytab
#   5 - Principal name or realm not found in keytab
failed_when: ipagetkeytab.rc != 0 and ipagetkeytab.rc != 3 and 
ipagetkeytab.rc != 5
when: "(_found_file.stdout | length) == 0"

  - name: Copy http.keytab to /etc/cockpit/krb5.keytab
ansible.builtin.copy:
  src: "{{ _found_file.stdout }}"
  dest: /etc/cockpit/krb5.keytab
  remote_src: true
  mode: "0600"
when: "(_found_file | length) != 0"

  - name: Play the role fedora.linux_system_roles.certificate
ansible.builtin.include_role:
  name: fedora.linux_system_roles.certificate
vars:
  certificate_requests:
  - name: /etc/cockpit/ws-certs.d/50-from-certmonger
dns: '{{ ansible_fqdn }}'
ip:
- '{{ ansible_default_ipv4.address }}'
- "{{ ansible_all_ipv6_addresses | select('match', 
'^fd23:e163:19f7:1234:') | first }}"
ca: ipa
principal: 'cockpit/{{ ansible_fqdn }}@{{ ansible_domain | upper }}'
owner: root
group: cockpit-ws
  # Cockpit refreshes the certs automatically

  handlers:
  - name: Daemon reload
ansible.builtin.systemd:
  daemon_reload: true
---

Hope that helps
Jochen

-- 
This space is 

[Freeipa-users] Re: KRA installation problem

[Jochen Kellner via FreeIPA-users]

Martin Jackson via FreeIPA-users 
writes:

> The "unexpected cert" warnings are of long standing and  are because I
> have certmonger-managed certs for cockpit on the controller.

I do have an ansible playbook to add these cert requests to the ignore
configuration:

  # Another WARNING is generated for the custom tls certificate
  # for cockpit - that needs to be ignored with
  # [excludes]\nkey=20210910141452 (certmonger request id)
  - name: get the certificate request for cockpit from certmonger
ansible.builtin.command:
  # -l gives only the filename of the request
  cmd: grep -lr cockpit
  chdir: /var/lib/certmonger/requests
register: cert_request
# Run the task in check mode too - we gather data...
check_mode: false
# Don't report changes in any case
changed_when: false 
 # And we don't fail
failed_when: false

  # In our installation we do have only ONE certificate extra.
  # So, let's just use the first(only) file found.
  # If that assumption changes, we need to change the tasks...
  - name: store certificate request id if found
ansible.builtin.set_fact:
  request_id: "{{ cert_request.stdout_lines | first }}"
  when_changed: false
when: cert_request.rc == 0

  # Generate the file /etc/ipahealthcheck/ipahealthcheck.conf from
  # a template: Add a timeout (20 seconds instead of 10) and
  # exclude false positive checks (cockpit cert and temporary
  # errors during upgrades (e.g. Fedora 36->37). Fedora 36's
  # ipa-healthcheck can't connect to KRA on Fedora 37.
  - name: Add more time until timeout for ipa-healthcheck
ansible.builtin.template:
  src: files/etc/ipahealthcheck.j2
  dest: /etc/ipahealthcheck/ipahealthcheck.conf
  mode: "0644"


The template file:
[default]
timeout=20

[excludes]
{% if request_id is defined %}
key={{ request_id }}
{% endif %}

-- 
This space is intentionally left blank.
___
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: Show expiring certificates issued by IPA CA

[Jochen Kellner via FreeIPA-users]

Rob Crittenden via FreeIPA-users 
writes:

> Jochen Kellner via FreeIPA-users wrote:
>> Orion Poplawski via FreeIPA-users 
>> writes:
>> 
>>> Does anyone know of a script or way to get a list of certificates issued by
>>> the IPA CA that are about to expire?
>> 
>> I do have a small script for byobu that warns when certificates are
>> about to expire and I verify refresh really works - that's only useful
>> for small installations with a small number of certificates.
>> 
>> In short: get a time interval with date and feed the dates into "ipa
>> cert-find". Have fun!
>
> There is a --status option you can set to valid which should return only
> currently valid certs (e.g. no revoked, expired, etc).

Thanks for the tip - that will make the script simpler...

Jochen

-- 
This space is intentionally left blank.
___
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: Show expiring certificates issued by IPA CA

[Jochen Kellner via FreeIPA-users]

Orion Poplawski via FreeIPA-users 
writes:

> Does anyone know of a script or way to get a list of certificates issued by
> the IPA CA that are about to expire?

I do have a small script for byobu that warns when certificates are
about to expire and I verify refresh really works - that's only useful
for small installations with a small number of certificates.

In short: get a time interval with date and feed the dates into "ipa
cert-find". Have fun!

#! /bin/bash
#
# Display the expiring certificates for the next few weeks
# This is called from byobu every 20 minutes
#
now=$(date   +"%Y-%m-%d")
end=$(date -d "+27 days" +"%Y-%m-%d")

count=0
revoked=0

# If we call the script manually with "--verbose", give a list
# of the expiring certificates - display subject, expiry date and
# serial number. Stop the script execution.
if [ "x$1" = "x--verbose" ]; then
env LC_ALL=C.UTF-8 KRB5_CLIENT_KTNAME=~/work/freeipa/jochen.keytab \
ipa cert-find --validnotafter-from="$now" --validnotafter-to="$end" | \
grep -E "(Subject|Not After|Serial number):"
exit
fi

# Count the expiring and possibly revoked certificates
eval "$(env LC_ALL=C.UTF-8 ipa cert-find --validnotafter-from="$now" 
--validnotafter-to="$end" | \
awk '/certificates matched/ { count=$1 } /REVOKED/ { revoked++ } END { 
printf("count=%d\nrevoked=%d\n", count, revoked) }')"

# If no cert is near expiry - display nothing
if [ "$count" -ne 0 ]; then
if [ "$count" -eq "$revoked" ]; then
# all expiring certificates are also revoked - display green
echo "#[fg=green]$count certs, $revoked revoked#[default]"
else
# there are expiring certificates which are possibly still active
# Looking for a already renewed certificate seems to be
# expensive performance-wise.
echo "#[bg=red]$count certs, $revoked revoked#[default]"
fi
fi


-- 
This space is intentionally left blank.
___
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: Healthckeck help

[Jochen Kellner via FreeIPA-users]

Bob Strachan via FreeIPA-users 
writes:

> At some point and I believe it was when we got to Rhel8.6 we started
> getting hc errors with this type of message:
> "msg": "Certificate 'subsystemCert cert-pki-ca' does not match the
> value of kra.subsystem.cert in
> /var/lib/pki/pki-tomcat/kra/conf/CS.cfg"

My analysis is documented here, more or less what you found:
https://pagure.io/freeipa/issue/9277

I've posted my take on an ansible script to fix my servers:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CEHJ6FE7N5D2XJ7ZCGHN76OX4GMBMOIV/

HTH
Jochen

-- 
This space is intentionally left blank.
___
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: Adding roles

[Jochen Kellner via FreeIPA-users]

Philippe de Rochambeau via FreeIPA-users
 writes:

> Hello,
> is there an ipa command called role-add? I couldn’t find it in the man.
> Furthermore, let’s say you wish to 400 roles to FreeIPA using the CLI.
> Would you recommend backing-up FreeIPA before issuing 400 role-adds?
> Can role-adds fail or cause exceptions?

Please see "ipa help topics" and "ipa help role". I'd do no special
backups before using "ipa role-add", but you should at least write a log
so you can check all is well.

Jochen

-- 
This space is intentionally left blank.
___
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: HTTP certificate expired

[Jochen Kellner via FreeIPA-users]

Juan Pablo Lorier via FreeIPA-users
 writes:

> Hi Rob,
>
> All dates are good once I add the pin manually. The only problem is
> the NEWLY_ADDED_NEED_KEYINFO_READ_PIN that appears every time I run
> the updater. I don’t know what is not right with the certs. Maybe you
> can point me in a direction to look at the logs. Let me share the
> getcert list once I manually fixed the pin:

Can you perhaps compare the requests for one certificate before and
after the upgrade? The requests are stored in
/var/lib/certmonger/requests. Let's focus on one certificate first,
for example:
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert 
cert-pki-ca'

I'd try something like that:
- save /var/lib/certmonger/requests somewhere
- try the upgrade once again
- save /var/lib/certmonger/requests again, somwhere else
- compare and see what the differences really are

Depending on the differences - and needs some creative thinking:
- reset the system to the state before the upgrade
- stop certmonger
- replace /var/lib/certmonger/requests with the second copy (from after
  the upgrade)
- We need to get certmonger and ipa-server-upgrade be happy with these
  requests, so the request don't get changed during the next upgrade.

I've had a look at the logs of the last ipaupgrade.log. For each
certificcate I see:
2022-09-02T20:02:24Z INFO [Update certmonger certificate renewal
configuration]
...
2022-09-02T20:02:24Z INFO Certmonger certificate renewal configuration
already up-to-date

I guess the second line for you says something like "...config
updated". We need to see, if the lines between have some clues for us.

In a post upthread you posted the console output:
Missing or incorrect tracking request for certificates:
  /etc/pki/pki-tomcat/alias:auditSigningCert cert-pki-ca
  /etc/pki/pki-tomcat/alias:ocspSigningCert cert-pki-ca
  /etc/pki/pki-tomcat/alias:subsystemCert cert-pki-ca
  /etc/pki/pki-tomcat/alias:caSigningCert cert-pki-ca
Certmonger certificate renewal configuration updated

Also upthread you posted:
> 2022-11-30T16:07:49Z DEBUG Profile 'ECAdminCert' is already in LDAP and
> enabled; skipping
> 2022-11-30T16:07:49Z INFO Migrating profile 'acmeServerCert'
> 2022-11-30T16:07:49Z DEBUG request GET
> https://dc2.tnu.com.uy:8443/ca/rest/account/login
> 2022-11-30T16:07:49Z DEBUG request body ''
> 2022-11-30T16:07:54Z DEBUG httplib request failed:
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/site-packages/ipapython/dogtag.py", line

In my upgrade log this is after updating/checing the certmonger
requests. So my guess is there's something strange with your
configuration in /var/lib/certmonger/requests.

So, can you provide more of your ipaupgrade.log where the certmonger
requests are checked/updated and one request before/after?

Jochen

-- 
This space is intentionally left blank.
___
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: HTTP certificate expired

[Jochen Kellner via FreeIPA-users]

Hello Juan,

Juan Pablo Lorier via FreeIPA-users
 writes:

> You are right, there are several certificates stuck in dc2:
>
> getcert list
...
> Request ID '20221130160320':
>   status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN

My google-fu point to that comment in an issue:
https://github.com/freeipa/freeipa-healthcheck/issues/123#issuecomment-659962943
That has the commands to fix the issue.

Another possibility should be to stop-tracking the certificates and run
ipa-server-upgrade which should restore the trackings. Right?

Jochen

-- 
This space is intentionally left blank.
___
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: Local account override IPA account

[Jochen Kellner via FreeIPA-users]

Hello Kevin,

Kevin Vasko via FreeIPA-users 
writes:

> I know this is probably stupid but we have a server with a local
> account (let’s call this local user “user1”). This server and its
> install predated our IPA install. This local user also has sudoers
> exception for this account for a “NOPASSWD” locally on this machine
> and this machine alone.
>
> After some period of time (it’s been like this for years), we added
> this “user1” account to FreeIPA so we could use it on other select
> machine. We kept using the local account as if nothing changed.
>
...
>
> If I remove “sss” from the nsswitch sudoers line it works as expected. 
>
> Is this a regression in sssd or something else Im missing?

I don't think it's a pure regression. I think the supported way to
"migrate" a former local user to IPA with another uid or others is to
define an id view for user1 on the ubuntu host and use uid 1000 there.
I'd hope that deleting the local user just changes the password to the
IPA one and sudo starts working.

If you want to debug your install further, you'd probably need to enable
tracing in sssd and look for clues,

Jochen

-- 
This space is intentionally left blank.
___
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-healthcheck: KRADogtagCertsConfigCheck

[Jochen Kellner via FreeIPA-users]

Hi,

Florence Blanc-Renaud via FreeIPA-users
 writes:

> Hi,
>
> On Wed, Nov 16, 2022 at 9:54 AM Jochen Kellner via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>>
>> Hello,
>>
>> On 2022-11-16 two of my four IPA server have this healthcheck error:
>>
>> freeipa1, freeipa2:
>>
>>   {
>> "source": "pki.server.healthcheck.meta.csconfig",
>> "check": "KRADogtagCertsConfigCheck",
...
>> When looking at the script, we call this for the cert:
>> python3.10/site-packages/ipaserver/install/cainstance.py:1157:
>> def update_cert_config(self, nickname, cert):
>>
>> Which calls that function:
>> python3.10/site-packages/ipaserver/install/dogtaginstance.py:555:
>> def update_cert_cs_cfg(self, directive, cert):
>>
>> But: there is no code to loop over the running services in pki-tomcat as
>> far as I can see. So we update ca/conf/CS.cfg, but not kra/conf/CS.cfg

>>
> Thanks for the detailed description, you completely nailed it.
> The post-save command does not update the certificate in the
> kra/conf/CS.cfg file but you can manually fix it.

You're welcome.

> Extract the new certificate from the NSS database, remove the header and
> footer and print it on a single line:
> # certutil -L -d /etc/pki/pki-tomcat/alias/ -n "Server-Cert cert-pki-ca" -a
> | tail -n +2 | head -n -1 | tr -d '\r\n'

I hope it will be fixed before the next certs expire :-)
But if not, here's my take in ansible to fix it when needed:

  - name: fetch ca.sslserver.cert from /var/lib/pki/pki-tomcat/ca/conf/CS.cfg
ansible.builtin.command:
  cmd: awk -F '=' '/^ca.sslserver.cert=/ { print $2 }' 
/var/lib/pki/pki-tomcat/ca/conf/CS.cfg
register: ca_sslserver_cert
check_mode: false
changed_when: false

  - name: fetch kra.sslserver.cert= from /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
ansible.builtin.command:
  cmd: awk -F '=' '/^kra.sslserver.cert=/ { print $2 }' 
/var/lib/pki/pki-tomcat/kra/conf/CS.cfg
register: kra_sslserver_cert
check_mode: false
changed_when: false

  - name: fix ipa-healthcheck, KRADogtagCertsConfigCheck
ansible.builtin.lineinfile:
  dest: /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
  # regexp: '^hosts: (.*)\s*\smyhostname(\s.*)$'
  regexp: '^kra.sslserver.cert='
  line: 'kra.sslserver.cert={{ ca_sslserver_cert.stdout }}'
  owner: pkiuser
  group: pkiuser
  mode: '0660'
  backup: true
when: ca_sslserver_cert.stdout != kra_sslserver_cert.stdout
notify: restart pki-tomcat

> Could you open a ticket against freeipa at https://pagure.io/freeipa/issues
> so that we fix the post-save command? It looks like it doesn't take into
> account the KRA certificates.

I've opened that ticket: https://pagure.io/freeipa/issue/9277

Thanks for your confirmation,
Jochen

-- 
This space is intentionally left blank.
___
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-healthcheck: KRADogtagCertsConfigCheck

[Jochen Kellner via FreeIPA-users]

Hello,

On 2022-11-16 two of my four IPA server have this healthcheck error:

freeipa1, freeipa2:

  {
"source": "pki.server.healthcheck.meta.csconfig",
"check": "KRADogtagCertsConfigCheck",
"result": "ERROR",
"uuid": "892ad5b7-8612-4476-8120-2a5fe6c6b005",
"when": "20221116030029Z",
"duration": "0.024925",
"kw": {
  "key": "kra_sslserver",
  "nickname": "Server-Cert cert-pki-ca",
  "directive": "kra.sslserver.cert",
  "configfile": "/var/lib/pki/pki-tomcat/kra/conf/CS.cfg",
  "msg": "Certificate 'Server-Cert cert-pki-ca' does not match the value of 
kra.sslserver.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg"
}
  },

The servers freeipa1-3 are Fedora 36, freeipa4 is Fedora 37 - all uptodate.

All files /var/lib/pki/pki-tomcat/kra/conf/CS.cfg have changed last
in Nov/Dec 2021. Most likely due to me looking at that issue and only
"fixing" the error but not investigating the root cause. Let's see if we
can remedy that.

On freeipa1, the "Server-Cert cert-pki-ca" has been refreshed on 2022-11-13 
15:27:35 CET.
On freeipa2, the "Server-Cert cert-pki-ca" has been refreshed on 2022-11-11 
15:22:12 CET.

The certificates on freeipa3 and freeipa4 will be refreshed in Nov 2023.

On freeipa2 there are these CS.cfg files:
[root@freeipa2 ~]# ls -l /var/lib/pki/pki-tomcat/*/conf/CS.cfg
-rw-rw. 1 pkiuser pkiuser 85469 11. Nov 15:22 
/var/lib/pki/pki-tomcat/ca/conf/CS.cfg
-rw-rw. 1 pkiuser pkiuser 34418 18. Nov 2021  
/var/lib/pki/pki-tomcat/kra/conf/CS.cfg

So it looks like the helper only refreshed the cert in ca, not on kra.
The certificate request has this post-save command:

post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"Server-Cert cert-pki-ca"

When looking at the script, we call this for the cert:
python3.10/site-packages/ipaserver/install/cainstance.py:1157:
def update_cert_config(self, nickname, cert):

Which calls that function:
python3.10/site-packages/ipaserver/install/dogtaginstance.py:555:
def update_cert_cs_cfg(self, directive, cert):

But: there is no code to loop over the running services in pki-tomcat as
far as I can see. So we update ca/conf/CS.cfg, but not kra/conf/CS.cfg

Some related discussions:
https://bugzilla.redhat.com/show_bug.cgi?id=1869893 says:

  3.  Though the subsystems seem to be working without errors so far, we
still would like to have copies of the cert in CS.cfg...  In future,
these redundant copies of cert will be removed from CS.cfg and the code
will be altered to retrieve certs from its NSSDB.

I've collected the logs of the certificate refresh on freeipa2 and can
provide them, but there was no related error as far as I can see.

PKI thinks that CA and KRA are enabled in this instance:

[pkiuser@freeipa2 ~]$ pki-server status
  Instance ID: pki-tomcat
  Active: True
  Nuxwdog Enabled: False
  Unsecure Port: 8080
  Secure Port: 8443
  AJP Port: 8009
  Tomcat Port: 8005

  CA Subsystem:
Type:CA Clone (Security Domain)
SD Name: IPA
SD Registration URL: https://freeipa2.example.org:8443
Enabled: True
Unsecure URL:http://freeipa2.example.org:8080/ca/ee/ca
Secure Agent URL:https://freeipa2.example.org:8443/ca/agent/ca
Secure EE URL:   https://freeipa2.example.org:8443/ca/ee/ca
Secure Admin URL:https://freeipa2.example.org:8443/ca/services
PKI Console URL: https://freeipa2.example.org:8443/ca

  KRA Subsystem:
Type:KRA
SD Name: IPA
SD Registration URL: https://freeipa2.example.org:443
Enabled: True
Secure Agent URL:https://freeipa2.example.org:8443/kra/agent/kra
Secure Admin URL:https://freeipa2.example.org:8443/kra/services
PKI Console URL: https://freeipa2.example.org:8443/kra

Is my analysis correct? What would be the right fix?

Jochen

-- 
This space is intentionally left blank.
___
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 API - Fetch keytab

[Jochen Kellner via FreeIPA-users]

Ronald Wimmer via FreeIPA-users 
writes:

>> Jochen already provided you the required commands. They can be
>> automated
>> easily.
>
> I was still thinking about how to do that from the AIX side. I'm
> sorry... Obviously I could need more coffee. ;-)

A lot of what can be done depends on what you use as AIX automation. If
you still use shell scripts - ssh to a linux host is your most likely
solution.  If you use something like ansible, you might want to check
"delegate_to" in the ansible documentation. In the unlikely event you
use SALT, have a look at orchestration. For other tool I declare total
ignorance.

There are lots and lots of possible solutions.

Just a hint how you might handle authentication for IPA commands: Add a
user to IPA that has the role "Enrollment Administrator". Get a keytab
for that user and store it at a save place on your IPA client. You
should be able to run "ipa" and other commands with and not giving
name/password on the command line:
  env KRB5_CLIENT_KTNAME=/path/to/key.tab ipa ...
(you might need to install urllib-gssapi or python3-urllib-gssapi)

That would still need some experimenting, but I'm sure it will work in
the end.

Remember that the AIX host and freeipa need to agree what's the last
kvno is - That might be a problem while experimenting.

Jochen
-- 
This space is intentionally left blank.
___
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 API - Fetch keytab

[Jochen Kellner via FreeIPA-users]

Hello Ronald,

Ronald Wimmer via FreeIPA-users 
writes:

> On 02.11.22 18:20, Rob Crittenden via FreeIPA-users wrote:
>> Ronald Wimmer via FreeIPA-users wrote:
>>> In order to integrate our AIX clients we do have to take two steps
>>> manually:
>>>
>>> 1) Enrolling the host
>>> 2) Fetching the keytab file for this particular host
>>>
>>> A quick search in the WebGUIs API browser revealed a host_add method but
>>> I cannot find a method for fetching a keytab file. Did I miss something
>>> here?
>> There is no IPA API to retrieve a keytab[1]. You should use
>> ipa-getkeytab.
>
> There is no ipa-getkeytab on AIX. So I need to fetch an IPA client's
> keytab from LDAP, right?

I'd do the following:

1. Enroll the host in freeipa:
   ipa host-add aix.example.org --ip-address=192.168.30.x
2. Allow my user to create a keytab:
   ipa host-allow-create-keytab aix.example.org --users=jochen
3. get the keytab:
   ipa-getkeytab -p host/aix.jochen.org -k aix.keytab
   Keytab successfully retrieved and stored in: aix.keytab
4. Transfer the keytab to the AIX host

HTH
Jochen
-- 
This space is intentionally left blank.
___
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: /run/ipa/ccaches filling

[Jochen Kellner via FreeIPA-users]

Charles Hedrick via FreeIPA-users 
writes:

> it's active, but it seems not to do anything:
>
> ● ipa-ccache-sweep.timer - Remove Expired Kerberos Credential Caches
>  Loaded: loaded (/usr/lib/systemd/system/ipa-ccache-sweep.timer; enabled; 
> vendor preset: disabled)
> -
>
> I believe the intent is that it should run every 12 hours. It doesn't
> seem to be doing so. From a web discussion:

That's the same on my system... I did enable and start the timer with my
local ansible plav - but that only worked for the current boot.

> OnUnitActiveSec does indeed refer to the time since the service
> referred to by the timer has run.  But if you only use OnUnitActiveSec
> and no other trigger then issue the command to start or enable
> foo.timer, foo.service will never run.  Why would it, no trigger would
> ever be activated in the first place: something needs to trigger the
> first run of foo.service in order to for you to ever have 3 seconds
> pass since it was last run.
>
> So in other words, OnUnitActiveSec can be used to define the interval
> between repetitions, but another trigger (like OnActiveSec or
> OnBootSec) would be needed to trigger the first run of foo.service to
> get the ball rolling.

In other words: you must also enable the
/usr/lib/systemd/system/ipa-ccache-sweep.service.
That way it will run once at system reboot and later every 12
hours. I've just changed my playbook and I'll see with the next reboot
how that works out.

Jochen

-- 
This space is intentionally left blank.
___
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: /run/ipa/ccaches filling

[Jochen Kellner via FreeIPA-users]

Charles Hedrick via FreeIPA-users 
writes:

> RHEL 9.0. /run/ipa/ccaches is filling with credential caches. Many are too 
> old to be valid.
>
> I assume it's safe to have a cron job delete any more than a day old?
> (that's our maxmum lifetime.) I can't see the lifetime directly,
> because they are encrypted.

On my system I have a (disabled( systemd-timer named
ipa-ccache-sweep.timer. My guess would be that it get's enabled on new
installs, but somehow missed on updates. See the release notes of 4.9.9:
https://www.freeipa.org/page/Releases/4.9.9

Jochen

-- 
This space is intentionally left blank.
___
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 prompting/2fa

[Jochen Kellner via FreeIPA-users]

Hello,
Jacob M Cutright via FreeIPA-users
 writes:

> It would be nice if ansible.cfg had keytab support

I'm not sure what you mean/want here.  I'm using an LDAP inventory from
FreeIPA in ansible. Authentication on the clients uses authorized_keys
here (no kerberos). Until recently I did a manual "kinit -t
/etc/ansible/ansible.keytab -k ansible/echidna.example.org! before
running ansible. I've now seen two other possibilites to have a TGT when
running ansible.

Recently I looked into gssproxy. Once it is correctly set uo, run
ansible wirh environment "GSS_USE_PROXY=yes". This is my gssproxy,conf
snippet:

root# cat:/etc/gssproxy/50-ansible.conf
[service/ansible]
  mechs = krb5
  cred_store = client_keytab:/etc/ansible/ansible.keytab
  cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
  cred_usage = initiate
  # program = /usr/bin/python3.9
  euid = ansible

The other possibility was to set KRB5_CLIENT_KTNAME:
export KRB5_CLIENT_KTNAME=/etc/ansible/ansible.keytab
This doesn't require gssproxy, but has the keytab accessible to user
ansible.

Both options work for me - take your pick :-)

Jochen

-- 
This space is intentionally left blank.
___
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: No server certificates found in /xx/http.pem The ipa-server-certinstall command failed.

[Jochen Kellner via FreeIPA-users]

Hi,

Rob Crittenden via FreeIPA-users 
writes:

> Documents like this are for testing purposes only. We don't want to
> encourage/enable users to roll their own PKI solution as it is bound to
> lead to problems.

I can confirm it's a real problem.

> The mariadb instructions issue 10-year server certificates which is well
> out of best practices for production systems.  It also almost guarantees
> that this will all have to be re-done from scratch because in 10 years
> either nobody will remember how to issue new certificates or the CA key
> will be lost to time. The certificates it generates also don't follow
> X.509 best practices regarding extensions.
>
> They may work fine for you but it's a time bomb and you could have
> interoperability problems.

I used to have a little CA with easyCA and created certificates for
internal use for a couple of years. Once the browser world moved to
newer requirements I needed to recreate some server certs. The last blow
was that the CA signing key was no longer accepted by the browsers. When
that happened I replaced all cert with FreeIPA issued certs and never
looked back. certmonger is a killer tool here - no more manual
certificate switches...

I assume we'll see stronger requirements every couple of years now.

Jochen

-- 
This space is intentionally left blank.
___
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: sudo rules and globbing

[Jochen Kellner via FreeIPA-users]

Rob Crittenden via FreeIPA-users 
writes:

>
> It may very well depend on the version of sudo you have on the client(s)
> whether regular expressions are supported or not.

In sudo 1.9.10 (released 2022-03-03) has this in the news:

Added support for using POSIX extended regular expressions in sudoers
rules. A command and/or arguments in sudoers are treated as a regular
expression if they start with a ‘^’ character and end with a ‘$’. The
command and arguments are matched separately, either one (or both) may
be a regular expression. Bug #578, GitHub issue #15.

On Debian 11 I have sudo 1.9.5 - there seems to be only globbing, no
regex support.

Jochen

-- 
This space is intentionally left blank.
___
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-client 4.9.8 in Debian 11 backports

[Jochen Kellner via FreeIPA-users]

Hello Timo,

Timo Aaltonen via FreeIPA-users 
writes:

> freeipa-client is finally in bullseye-backports, feel free to report
> bugs (if any) on bugs.debian.org.

Thank you - that is good news!  I've used the client from snapshots:
https://snapshot.debian.org/archive/debian/20210121

I'll update my systems to the backport packages - Thanks a lot!

Jochen

-- 
This space is intentionally left blank.
___
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: Deleting this server is not allowed as it would leave your installation without a KRA.

[Jochen Kellner via FreeIPA-users]

Rob Crittenden via FreeIPA-users 
writes:

> Jochen Kellner via FreeIPA-users wrote:
>> 
>> Hi,
>> 
>> I'm about to decomission one of my IPA replicas running on up to date
>> fedora 35 (freeipa-server-common-4.9.7-4.fc35.noarch). On my CA renewal
>> master (freeipa1.example.org) I try to remove freeipa4.example.org:
>> 
>> [root@freeipa1 ~]# ipa server-del freeipa4.example.org
>> Removing freeipa4.example.org from replication topology, please wait...
>> ipa: ERROR: Server removal aborted: Deleting this server is not allowed as 
>> it would leave your installation without a KRA..
>> 
...
>> I think the message is wrong:
>> I had a took at plugins/server.py:
>> 
>>  509 if self.api.Command.ca_is_enabled()['result']:
>>  510 try:
>>  511 roles = self.api.Command.server_role_find(
>>  512 server_server=hostname,
>> 
>> => Do we really need to search for the hostname here?  We will
>> always find out that there is only one server left...  When I remove
>> that parameter deletion would continue - but I didn't really run the
>> rest of the deletion yet.
>> 
>> ipa server-role-find --server=freeipa4.example.org --role="KRA server"
>> really returns one entry.
>> 
>>  513 role_servrole='KRA server',
>>  514 status='enabled',
>>  515 include_master=True,
>>  516 )['result']
>>  517 except errors.NotFound:
>>  518 roles = ()
>>  519 if len(roles) == 1 and roles[0]['server_server'] == 
>> hostname:
>>  520 handler(
>>  521 _("Deleting this server is not allowed as it would "
>>  522   "leave your installation without a KRA."),
>>  523 ignore_last_of_role)
>> 
>> The commit that added the code was
>> https://github.com/freeipa/freeipa/commit/10bd66dd1a14fc0bd39c489d0d0af76b0f720c96
>> and should fix https://pagure.io/freeipa/issue/8397
>> 
>> Do I miss something else?
>
> This is commit 0b9adf1d8d5efb48e734650e4101e8816b01e1d3 in the ipa-4-9
> branch and was first tagged in 4.9.7
>
> I'll take another look. You're right, the server match looks suspicious.

I've seen https://github.com/freeipa/freeipa/pull/6101 and it works for
me. Thanks!

Jochen

-- 
This space is intentionally left blank.
___
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: locale de_DE.UTF-8 and internel error

[Jochen Kellner via FreeIPA-users]

Alexander Bokovoy via FreeIPA-users
 writes:

> I think you can remove _() in local handler() function in
> _ensure_last_of_role():
>
> else:
> raise errors.ServerRemovalError(reason=_(msg))
>
> Looks like all the callers give already gettext-enabled message (wrapped
> with _() already).
>
> Can you submit a pull request with that?

Please have a look at https://github.com/freeipa/freeipa/pull/6097

Jochen

-- 
This space is intentionally left blank.
___
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: locale de_DE.UTF-8 and internel error

[Jochen Kellner via FreeIPA-users]

Hello Alexander,

Alexander Bokovoy via FreeIPA-users
 writes:

> On su, 21 marras 2021, Jochen Kellner via FreeIPA-users wrote:
>>
>>Hi,
>>
>>I tried removing a replica and got an internal error:
>>
>>jochen@freeipa1:~$ ipa server-del freeipa4.example.org
>>Removing freeipa4.example.org from replication topology, please wait...
>>ipa: ERROR: Ein interner Fehler ist aufgetreten
>>
...
>>]   File "/usr/lib64/python3.10/gettext.py", line 498, in gettext
>>] tmsg = self._catalog.get(message, missing)
>>] TypeError: unhashable type: 'Gettext'
>>] ipa: INFO: [jsonserver_session] ad...@example.org:
>> server_del/1(['freeipa4.example.org'], version='2.245'):
>> InternalError

> I think you can remove _() in local handler() function in
> _ensure_last_of_role():
>
> else:
> raise errors.ServerRemovalError(reason=_(msg))
>
> Looks like all the callers give already gettext-enabled message (wrapped
> with _() already).
>
> Can you submit a pull request with that?

That seems to work. I'll prepare a pull request.

Jochen

-- 
This space is intentionally left blank.
___
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] locale de_DE.UTF-8 and internel error

[Jochen Kellner via FreeIPA-users]

Hi,

I tried removing a replica and got an internal error:

jochen@freeipa1:~$ ipa server-del freeipa4.example.org
Removing freeipa4.example.org from replication topology, please wait...
ipa: ERROR: Ein interner Fehler ist aufgetreten

I'm running with LANG=de_DE.UTF-8. Using en_US.UTF-8 would be ok.
In the httpd error_log:

] ipa: ERROR: non-public: TypeError: unhashable type: 'Gettext'
] Traceback (most recent call last):
]   File "/usr/lib/python3.10/site-packags/ipaserver/rpcserver.py", line 407, 
in wsgi_execute
] result = command(*args, **options)
]   File "/usr/lib/python3.10/site-packages/ipalib/frontend.py", line 471, in 
__call__
] return self.__do_call(*args, **options)
]   File "/usr/lib/python3.10/site-packages/ipalib/frontend.py", line 499, in 
__do_call
] ret = self.run(*args, **options)
]   File "/usr/lib/python3.10/site-packages/ipalib/frontend.py", line 821, in 
run
] return self.execute(*args, **options)
]   File "/usr/lib/python3.10/site-packages/ipaserver/plugins/baseldap.py", 
line 1686, in execute
] delete_entry(pkey)
]   File "/usr/lib/python3.10/site-packages/ipaserver/plugins/baseldap.py", 
line 1637, in delete_entry
] dn = callback(self, ldap, dn, *nkeys, **options)
]   File "/usr/lib/python3.10/site-packages/ipaserver/plugins/server.py", line 
755, in pre_callback
] self._ensure_last_of_role(
]   File "/usr/lib/python3.10/site-packages/ipaserver/plugins/server.py", line 
520, in _ensure_last_of_role
] handler(
]   File "/usr/lib/python3.10/site-packages/ipaserver/plugins/server.py", line 
482, in handler
] raise errors.ServerRemovalError(reason=_(msg))
]   File "/usr/lib/python3.10/site-packages/ipalib/errors.py", line 269, in 
__init__
] messages.process_message_arguments(self, format, message, **kw)
]   File "/usr/lib/python3.10/site-packages/ipalib/messages.py", line 55, in 
process_message_arguments
] kw[key] = unicode(value)
]   File "/usr/lib/python3.10/site-packages/ipalib/text.py", line 296, in 
__str__
] return unicode(self.as_unicode())
]   File "/usr/lib/python3.10/site-packages/ipalib/text.py", line 293, in 
as_unicode
] return t.gettext(self.msg)
]   File "/usr/lib64/python3.10/gettext.py", line 498, in gettext
] tmsg = self._catalog.get(message, missing)
] TypeError: unhashable type: 'Gettext'
] ipa: INFO: [jsonserver_session] ad...@example.org: 
server_del/1(['freeipa4.example.org'], version='2.245'): InternalError

Other commands like "ipa server-role-find --server=freeipa4.example.org"
work ok and display translated messaged.

Any ideas?

Jochen

-- 
This space is intentionally left blank.
___
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] Deleting this server is not allowed as it would leave your installation without a KRA.

[Jochen Kellner via FreeIPA-users]

Hi,

I'm about to decomission one of my IPA replicas running on up to date
fedora 35 (freeipa-server-common-4.9.7-4.fc35.noarch). On my CA renewal
master (freeipa1.example.org) I try to remove freeipa4.example.org:

[root@freeipa1 ~]# ipa server-del freeipa4.example.org
Removing freeipa4.example.org from replication topology, please wait...
ipa: ERROR: Server removal aborted: Deleting this server is not allowed as it 
would leave your installation without a KRA..

I think the message is wrong:

[root@freeipa1 ~]# ipa server-role-find --role="KRA server" --status=enabled
--
4 server roles matched
--
  Server name: freeipa1.example.org
  Role name: KRA server
  Role status: enabled

  Server name: freeipa2.example.org
  Role name: KRA server
  Role status: enabled

  Server name: freeipa3.example.org
  Role name: KRA server
  Role status: enabled

  Server name: freeipa4.example.org
  Role name: KRA server
  Role status: enabled

Number of entries returned 4


I had a took at plugins/server.py:

 509 if self.api.Command.ca_is_enabled()['result']:
 510 try:
 511 roles = self.api.Command.server_role_find(
 512 server_server=hostname,

=> Do we really need to search for the hostname here?  We will
always find out that there is only one server left...  When I remove
that parameter deletion would continue - but I didn't really run the
rest of the deletion yet.

ipa server-role-find --server=freeipa4.example.org --role="KRA server"
really returns one entry.

 513 role_servrole='KRA server',
 514 status='enabled',
 515 include_master=True,
 516 )['result']
 517 except errors.NotFound:
 518 roles = ()
 519 if len(roles) == 1 and roles[0]['server_server'] == hostname:
 520 handler(
 521 _("Deleting this server is not allowed as it would "
 522   "leave your installation without a KRA."),
 523 ignore_last_of_role)

The commit that added the code was
https://github.com/freeipa/freeipa/commit/10bd66dd1a14fc0bd39c489d0d0af76b0f720c96
and should fix https://pagure.io/freeipa/issue/8397

Do I miss something else?

Jochen

-- 
This space is intentionally left blank.
___
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: KRA: problems renewing 'storageCert cert-pki-kra'

[Jochen Kellner via FreeIPA-users]

Jochen Kellner via FreeIPA-users 
writes:

> And that's due to an error I made when trying to fix KRA. This is an
> excerpt from "getcert list":
>
> Request ID '20210210143948':
> status: MONITORING
> ca-error: Server at 
> "http://freeipa1.example.org:8080/ca/ee/ca/profileSubmit; replied: Policy Set 
> Not Found
...
> That's from the ca error log:
>
> 2021-11-14 15:09:58 [http-nio-8080-exec-15] INFO: EnrollProfile: Creating 
> ernrollment request 139960063
> 2021-11-14 15:09:58 [http-nio-8080-exec-15] SEVERE: CertProcessor: no profile 
> policy set found
> 2021-11-14 15:09:58 [http-nio-8080-exec-15] SEVERE: ProfileSubmitServlet: 
> error in processing request: Policy Set Not Found
> Policy Set Not Found

After some more debugging and thinking and tinkering:
The CA Profile caStorageCert was broken in LDAP. I remove the entry, ran
ipa-server-upgrade which reloaded the profile from disk and finally the
certificate has been refreshed.

Now ipa-healthcheck is without errors on my CA renewal master. So I'm
now working on the replicas.

Jochen

-- 
This space is intentionally left blank.
___
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] KRA: problems renewing 'storageCert cert-pki-kra'

[Jochen Kellner via FreeIPA-users]

Hi,

I'm working to get the KRA subsystem in shape again. It has been broken
due to failed system replication (which is since fixed). There might be
lurking further problems - let's see what we can find out.

I'm working through ipa-healthcheck - currently on the CA renewal
master. The (last) error I'm having there is the following:

[
  {
"source": "ipahealthcheck.ipa.certs",
"check": "IPADogtagCertsMatchCheck",
"result": "ERROR",
"uuid": "70f767e8-19de-4426-94e0-6c7704a72895",
"when": "2024152924Z",
"duration": "2.801277",
"kw": {
  "key": "storageCert cert-pki-kra",
  "nickname": "storageCert cert-pki-kra",
  "dbdir": "/etc/pki/pki-tomcat/alias",
  "msg": "{nickname} certificate in NSS DB {dbdir} does not match entry in 
LDAP"
}
  }
]

[That certificate will expire in dezember.]

And that's due to an error I made when trying to fix KRA. This is an
excerpt from "getcert list":

Request ID '20210210143948':
status: MONITORING
ca-error: Server at 
"http://freeipa1.example.org:8080/ca/ee/ca/profileSubmit; replied: Policy Set 
Not Found
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='storageCert 
cert-pki-kra',token='NSS Certificate DB',pin s
et
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='storageCert 
cert-pki-kra',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=EXAMPLE.ORG
subject: CN=KRA Storage Certificate,O=IPA.EXAMPLE.ORG
issued: 2020-12-31 21:08:29 CET
expires: 2022-12-21 21:08:29 CET
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-clientAuth
profile: caStorageCert
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"storageCert cert-pki-kra"
track: yes
auto-renew: yes

That's the error - I copied the request from a temporary install but
failed to fix the subject (did not remove "IPA.")

subject: CN=KRA Storage Certificate,O=IPA.EXAMPLE.ORG

I tried to resubmit the certificate request with:

  getcert resubmit -i 20210210143948 -N "CN=KRA Storage 
Certificate,O=EXAMPLE.ORG"

Here's the redacted log:

Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Setting "CERTMONGER_REQ_SUBJECT" to "CN=KRA Storage Certificate,O=EXAMPLE.ORG" 
for child.
Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Setting "CERTMONGER_OPERATION" to "SUBMIT" for child.
Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Setting "CERTMONGER_CSR" to "-BEGIN NEW CERTIFICATE REQUEST-

Nov 14 15:09:57 freeipa1 certmonger[209808]: -END NEW CERTIFICATE 
REQUEST-
Nov 14 15:09:57 freeipa1 certmonger[209808]: " for child.
Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Setting "CERTMONGER_SPKAC" to "" for child.

Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Setting "CERTMONGER_SPKI" to "" for child.
Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Setting "CERTMONGER_LOCAL_CA_DIR" to "/var/lib/certmonger/local" for child.
Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Setting "CERTMONGER_KEY_TYPE" to "RSA" for child.
Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Setting "CERTMONGER_CA_NICKNAME" to "dogtag-ipa-ca-renew-agent" for child.
Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Setting "CERTMONGER_CA_PROFILE" to "caStorageCert" for child.
Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Setting "CERTMONGER_CERTIFICATE" to "-BEGIN CERTIFICATE-

Nov 14 15:09:57 freeipa1 certmonger[209808]: -END CERTIFICATE-
Nov 14 15:09:57 freeipa1 certmonger[209808]: " for child.
Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Redirecting stdin to /dev/null, leaving stdout and stderr open for child 
"/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit".
Nov 14 15:09:57 freeipa1 certmonger[209808]: 2021-11-14 15:09:57 [209808] 
Running enrollment helper 
"/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit".
Nov 14 15:09:58 freeipa1 certmonger[209234]: 2021-11-14 15:09:58 [209234] 
Certificate submission still ongoing.
Nov 14 15:09:58 freeipa1 certmonger[209234]: 2021-11-14 15:09:58 [209234] 
Certificate submission attempt complete.
Nov 14 15:09:58 freeipa1 certmonger[209234]: 2021-11-14 15:09:58 [209234] Child 
status = 2.
Nov 14 15:09:58 freeipa1 certmonger[209234]: 2021-11-14 15:09:58 [209234] Child 
output:
Nov 14 15:09:58 freeipa1 certmonger[209234]: "Server at 
"http://freeipa1.example.org:8080/ca/ee/ca/profileSubmit; replied: Policy Set 
Not Found
Nov 14 15:09:58 freeipa1 certmonger[209234]: "
Nov 14 15:09:58 

[Freeipa-users] Re: migrating NIS passwords to FreeIPA in Fedora 33 with {CRYPT} and RH sample nis-users.sh script

[Jochen Kellner via FreeIPA-users]

Hi,

Robert Kudyba via FreeIPA-users 
writes:

> Yes and I found a fix. All that is needed is to surround the echo command
> with double quotes at the top of the script where username is set:
> username="$(echo $line | cut -f1 -d:)"

For some of these errors using shellcheck might help. Not bulletproof,
but helpful.

Jochen

-- 
This space is intentionally left blank.
___
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: migrating NIS passwords to FreeIPA in Fedora 33 with {CRYPT} and RH sample nis-users.sh script

[Jochen Kellner via FreeIPA-users]

Robert Kudyba via FreeIPA-users 
writes:

> So now I put:
> ipa user-add $username --first=$first --last=$last \
>  --setattr userpassword='{CRYPT}$password1' --gidnumber=$gid

Try:
  --setattr "userpassword={CRYPT}$password1" --gidnumber=$gid


Jochen

-- 
This space is intentionally left blank.
___
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: Concurrent ssh to the same host fails after few successfully open sessions with Additional pre-authentication krb error.

[Jochen Kellner via FreeIPA-users]

Hello,
Rob Crittenden via FreeIPA-users 
writes:

> mir mal via FreeIPA-users wrote:
>> I'm still struggling to find a clue why it's happening, any help much 
>> appriciated.
>
> This stands out:
>
> Nov 30 10:15:46 csc-64 sshd[608090]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.6  user=c11
> Nov 30 10:15:46 csc-64 sshd[608090]: pam_sss(sshd:auth): authentication
> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.6 user=c11
> Nov 30 10:15:46 csc-64 sshd[608090]: pam_tally2(sshd:auth): user c11
> (193866) tally 52, deny 9
>
> An auth failure immediately followed by an auth success.

And: failure with pam_unix (local user?) and success with pam_sss.
On most Systems we have something like that in /etc/pam.d/password-auth
or common-auth:

auth[default=1 ignore=ignore success=ok] pam_usertype.so 
isregular
auth[default=1 ignore=ignore success=ok] pam_localuser.so
authsufficient   pam_unix.so nullok 
try_first_pass
auth[default=1 ignore=ignore success=ok] pam_usertype.so 
isregular
authsufficient   pam_sss.so forward_pass
authrequired pam_deny.so

so, call pam_unix only for local users, not IPA users.
Something like that?

Jochen

-- 
This space is intentionally left blank.
___
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 certificate doesn't validate in iOS

[Jochen Kellner via FreeIPA-users]

Hello Alexander,

Alexander Bokovoy via FreeIPA-users
 writes:

> Can you please show both your CA and the IMAP server public certificates
> in their entirety?

I think/hope we found the error in the iOS configuration, so I'll not
send the certificates now. If I'm wrong I'll get back to the list and
make sure to present the certificates.
Thanks a lot for your time and your help.

Jochen

-- 
This space is intentionally left blank.
___
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 certificate doesn't validate in iOS

[Jochen Kellner via FreeIPA-users]

Hello,

thanks for your suggestions, I'll answer below. TL;DR: seems to work now.

Fraser Tweedale via FreeIPA-users 
writes:

> First of all: is the IPA CA certificate (or if it is externally
> signed, one of the superior certificates) in the trust store on the
> user's iPhone?

I use the CA from FreeIPA and the CA certificate has been imported in
the trust store.
Using a web browser to access an internal website with an (older) IPA
issued certificate works/validates fine.

> On Sun, Sep 06, 2020 at 11:24:22AM +0200, Jochen Kellner via FreeIPA-users 
> wrote:
>> 
>> Hello,
>> 
>> I'm running IPA on current Fedora 32, freeipa-server-4.8.9-2 and 
>> pki-server-10.9.0-0.4
>> 
>> Today the certificate of my IMAP server (running on Debian Buster) was
>> automatically refreshed:
>> 
>> ,
>> | Request ID '20181003215953':
>> | status: MONITORING
>> | stuck: no
>> | key pair storage: 
>> type=FILE,location='/etc/ssl/private/imap.jochen.org.key'
>> | certificate: 
>> type=FILE,location='/etc/ssl/certs/imap.jochen.org.crt'
>> | CA: IPA
>> | issuer: CN=Certificate Authority,O=JOCHEN.ORG
>> | subject: CN=imap.jochen.org,O=JOCHEN.ORG
>> | expires: 2022-09-07 09:30:16 CEST
>> | dns: imap.jochen.org
>> | principal name: imap/jupiter.jochen@jochen.org
>> | key usage: 
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>> | eku: id-kp-serverAuth,id-kp-clientAuth
>> | pre-save command:
>> | post-save command: /root/refresh_cyrus_certificate.sh
>> | track: yes
>> | auto-renew: yes
>> `
>> 
>> On an iPhone one of my users gets a message that the certificate is not 
>> valid.
>>
> Was the previous certificate accepted, and the problem only occurs
> with the new certificate.  You did mention the recent renewal, but
> you please clarify on this point?

Yes, the old certificate was accepted without problems. Only after the
renewal the user got these messages.

>> Reason seems to be this: 
>> https://7402.org/blog/2019/new-self-signed-ssl-cert-ios-13.html
>> 
> This article does not suggest any reason why iOS would consider the
> certificate invalid.  If I missed something, please elaborate.

This is the part:

The new requirements for an SSL certificate to be accepted by iOS 13 and
macOS 10.15 are given in https://support.apple.com/en-us/HT210176. The
key points are:

Key size must be greater than or equal to 2048 bits.
Certificate must have a validity period of 825 days or fewer.
Don't sign the certificate with SHA-1.
DNS name must be in the Subject Alternative Name extension of the 
certificate.
Certificate must have an ExtendedKeyUsage containing serverAuth.


>> When I look at the certificate with openssl I see:
>> 
>> ,
>> | X509v3 extensions:
>> | X509v3 Authority Key Identifier: 
>> | 
>> keyid:4F:F8:45:3D:E8:06:4B:8D:BB:9D:D2:D1:8B:00:43:A1:07:16:A1:17
>> | 
>> | Authority Information Access: 
>> | OCSP - URI:http://ipa-ca.jochen.org/ca/ocsp
>> | 
>> | X509v3 Key Usage: critical
>> | Digital Signature, Non Repudiation, Key Encipherment, Data 
>> Encipherment
>> | X509v3 Extended Key Usage: 
>> | TLS Web Server Authentication, TLS Web Client 
>> Authentication
>> `
>> 
>> My current guess is that the "Key Usage: critical" is the reason for the iOS 
>> error.
>> 
> This is almost certainly not the issue.  "Critical" just means that
> a verifier must understand and process the extension, or else fail.
> Per RFC 5280 the Key Usage extension SHOULD be marked critical.
> The asserted values are appropriate for a TLS server.

Ok.

>> I've looked for the certprofiles and found these files:
>> 
>> ,
>> | [root@freeipa3 /]# find . -name \*caIPAserviceCert\* -ls
>> |   8510694  8 -rw-rw   1 pkiuser  pkiuser  6218 Mär  4  2020 
>> ./var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg
>> |   9332162  4 -rw-r--r--   1 root root  229 Aug 20 12:38 
>> ./usr/lib/python3.8/site-packages/ipaclient/csrgen/profiles/caIPAserviceCert.json
>> |  26138015  8 -rw-r--r--   1 root root 7014 Aug 20 12:37 
>> ./usr/share/ipa/profiles/caIPAserviceCert.UPGRADE.cfg
>> |  26138016  8 -rw-r--r--   1 root root 7294 Aug 20 12:37 
>> ./usr/share/ipa/profiles/caIPAserviceCert.cfg
>> |   9323278   

[Freeipa-users] FreeIPA certificate doesn't validate in iOS

[Jochen Kellner via FreeIPA-users]

Hello,

I'm running IPA on current Fedora 32, freeipa-server-4.8.9-2 and 
pki-server-10.9.0-0.4

Today the certificate of my IMAP server (running on Debian Buster) was
automatically refreshed:

,
| Request ID '20181003215953':
| status: MONITORING
| stuck: no
| key pair storage: 
type=FILE,location='/etc/ssl/private/imap.jochen.org.key'
| certificate: type=FILE,location='/etc/ssl/certs/imap.jochen.org.crt'
| CA: IPA
| issuer: CN=Certificate Authority,O=JOCHEN.ORG
| subject: CN=imap.jochen.org,O=JOCHEN.ORG
| expires: 2022-09-07 09:30:16 CEST
| dns: imap.jochen.org
| principal name: imap/jupiter.jochen@jochen.org
| key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
| eku: id-kp-serverAuth,id-kp-clientAuth
| pre-save command:
| post-save command: /root/refresh_cyrus_certificate.sh
| track: yes
| auto-renew: yes
`

On an iPhone one of my users gets a message that the certificate is not valid.
Reason seems to be this: 
https://7402.org/blog/2019/new-self-signed-ssl-cert-ios-13.html

When I look at the certificate with openssl I see:

,
| X509v3 extensions:
| X509v3 Authority Key Identifier: 
| 
keyid:4F:F8:45:3D:E8:06:4B:8D:BB:9D:D2:D1:8B:00:43:A1:07:16:A1:17
| 
| Authority Information Access: 
| OCSP - URI:http://ipa-ca.jochen.org/ca/ocsp
| 
| X509v3 Key Usage: critical
| Digital Signature, Non Repudiation, Key Encipherment, Data 
Encipherment
| X509v3 Extended Key Usage: 
| TLS Web Server Authentication, TLS Web Client Authentication
`

My current guess is that the "Key Usage: critical" is the reason for the iOS 
error.

I've looked for the certprofiles and found these files:

,
| [root@freeipa3 /]# find . -name \*caIPAserviceCert\* -ls
|   8510694  8 -rw-rw   1 pkiuser  pkiuser  6218 Mär  4  2020 
./var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg
|   9332162  4 -rw-r--r--   1 root root  229 Aug 20 12:38 
./usr/lib/python3.8/site-packages/ipaclient/csrgen/profiles/caIPAserviceCert.json
|  26138015  8 -rw-r--r--   1 root root 7014 Aug 20 12:37 
./usr/share/ipa/profiles/caIPAserviceCert.UPGRADE.cfg
|  26138016  8 -rw-r--r--   1 root root 7294 Aug 20 12:37 
./usr/share/ipa/profiles/caIPAserviceCert.cfg
|   9323278  8 -rw-r--r--   1 root root 6272 Jun 25 23:53 
./usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg
`

These files contain:

,
| policyset.serverCertSet.6.constraint.params.keyUsageCritical=true
| policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true
| policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true
| policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true
| policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true
| policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false
`

So I think this is where the critical comes from and the keyUsage defaults come 
from.

What I could use help with is the following:

1. I didn't find reports about the problem in pagure or the mailing
list. Am I really alone with this?

2. My FreeIPA has been installed years ago on Fedora, moved to CentOS
and this year back to Fedora by creating replicas. Has there been a
problem with upgrading the certprofiles?

3. How can I remove the options from the certificate request so that
certmonger gets a valid certificate?

Do I miss something else?

-- 
This space is intentionally left blank.
___
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: pki-tomcatd not starting

[Jochen Kellner via FreeIPA-users]

"Scott Z. via FreeIPA-users" 
writes:

> My current status is that I've done an ipactl restart
> --ignore-service-failure, my timedate value is once again current,

Your IDM server has the ntp role enables, so you can't go back in time
and user "ipactl start", because that is setting the time to current
again. So do the following:

- ipctl stop
- stop ntp if it is still running
- go back in time
- start each service manually that ipactl would do but skip ntp.

See if the CA is running. Then restart certmonger or resubmit the
requests. That should work.

Jochen

-- 
This space is intentionally left blank.
___
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: OTP Radius 5 seconds timeout

[Jochen Kellner via FreeIPA-users]

Jochen Kellner via FreeIPA-users 
writes:

> I see... I've looked again for my research concerning IPA OTP timeouts.
> These posts document the timeouts I found:
>
> https://www.redhat.com/archives/freeipa-users/2016-December/msg00239.html
> https://www.redhat.com/archives/freeipa-users/2016-December/msg00271.html

There's also a ticket:
https://pagure.io/freeipa/issue/7444

Jochen

-- 
This space is intentionally left blank.
___
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: OTP Radius 5 seconds timeout

[Jochen Kellner via FreeIPA-users]

Hi,

Sergiy Genyuk via FreeIPA-users 
writes:

> Radius server is DUO so when in FreeIPA radius server set it sends
> Access-Request to the DUO Radius server DUO check password against AD
> and then push Accept message to the user mobile app... then returns
> Access-Accept message back to FreeIPA.
>
> Of cause it takes some time so I have setup timeout in Radius section
> in the FreeIPA config but that's does not work. With any settings
> default timeout is 5 seconds :-(

I see... I've looked again for my research concerning IPA OTP timeouts.
These posts document the timeouts I found:

https://www.redhat.com/archives/freeipa-users/2016-December/msg00239.html
https://www.redhat.com/archives/freeipa-users/2016-December/msg00271.html

May they have some hints for you.

Jochen

-- 
This space is intentionally left blank.
___
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: OTP Radius 5 seconds timeout

[Jochen Kellner via FreeIPA-users]

Sergiy Genyuk via FreeIPA-users 
writes:

> Thank you for your reply, I do have ipv6 disabled and in capture do not see 
> failed attempts.
> In capture it is only ipv4:
>
> 1 0.0   xx.xx.xx.xx -> yy.yy.yy.yy   RADIUS 117 Access-Request(1) 
> (id=214, l=75)
> 2 7.889686902   yy.yy.yy.yy -> xx.xx.xx.xx   RADIUS 90 Access-Accept(2) 
> (id=214, l=48)
>
> If delay more then 5 seconds between request and reply  you going to get 
> request for password again :-(

So you should find out why RADIUS is spending so much time. What RADIUS
server do you use? What's your user store, and what do you use for OTP?
I did use freeradius and privacyidea.

I did research setting longer timeouts, but that proved not really
useful.

Jochen

-- 
This space is intentionally left blank.
___
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: OTP Radius 5 seconds timeout

[Jochen Kellner via FreeIPA-users]

Hello Sergiy,

Sergiy Genyuk via FreeIPA-users 
writes:

> I have setup radius proxy (DUO) and associate user with it. Everything works 
> except radius
> timeout. It is 5 seconds and you have to be blazing fast to push the button 
> :-)
> I did adjust radius timeout in freeipa to 30 seconds  but it is still 5 
> seconds. As well I
> have tried a trick with krb.conf [otp] settings, same still 5 seconds.
> Please point me to proper way to change radius timeout.

I had a similar problem some time ago. In my case FreeIPA did a DNS
query for the RADIUS server IP address. The answer was IPv6, but
freeradius didn't listen for IPv6. So FreeIPA did a retry with IPv4
after 5 or 6 seconds. I did see that when sniffing radius traffic on my
radius server.

Here's the diff for my configuration:

diff --git a/freeradius/radiusd.conf b/freeradius/radiusd.conf
index d80312e..85669c4 100644
--- a/freeradius/radiusd.conf
+++ b/freeradius/radiusd.conf
@@ -354,6 +354,18 @@ listen {
 #  clients = per_socket_clients
 }

+listen {
+ipv6addr = ::
+port = 0
+type = auth
+}
+listen {
+ipv6addr = ::
+port = 0
+type = acct
+}

I can't find the original thread in the archive, but check with "tcpdump
-i  port 1812" if you see a failed attempt with IPv6 on your radius
server followed some seconds later with IPv4.

Jochen

-- 
This space is intentionally left blank.
___
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: Problem with AD users after upgrade

[Jochen Kellner via FreeIPA-users]

Hello Ronald,

Ronald Wimmer via FreeIPA-users 
writes:

> I would highly appreciate if you could take a quick look and tell me
> how severe they are and what I can possibly do to fix them. I do not
> care about KRA because we did not use the feature at this point in
> time. KRA could be set up from scratch again - if possible. The
> replication conflicts sound much more troubeling...

I've also had the KRA certificate problem - it was relativly easy to
fix. I've just replaced the certificates in the CS.cfg files with the
certificates from LDAP (or WebUI - cut was my friend).

>   {
> "source": "pki.server.healthcheck.meta.csconfig",
...
>   "key": "kra_transport",
>   "nickname": "transportCert cert-pki-kra",
>   "directive": "kra.transport.cert",
>   "configfile": "/var/lib/pki/pki-tomcat/kra/conf/CS.cfg",
>   "msg": "Certificate 'transportCert cert-pki-kra' does not match
> the value of kra.transport.cert in
> /var/lib/pki/pki-tomcat/kra/conf/CS.cfg"

Regarding the replication errors - these look mostly like standard
permissions. You should follow the documentation on how to fix
replication errors. I'd expect that you probably can just remove the
conflict entry - but you need to check that.

Jochen

-- 
This space is intentionally left blank.
___
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-healthcheck with fresh replica

[Jochen Kellner via FreeIPA-users]

Jochen Kellner via FreeIPA-users 
writes:

> In IPA I have four certificates for "IPA RA" - one (the oldest) revoked,
> two are expired in 2017 and 2019 and one valid until next year.
>
> The certificate in CS.cfg is expired:
>
> Serial Number: 268173317 (0xffc0005)
> ...
> Validity
> Not Before: Dec 30 06:29:19 2017 GMT
> Not After : Dec 20 06:29:19 2019 GMT
> Subject: O = EXAMPLE.ORG, CN = KRA Transport Certificate
>
> certutl has the correct (valid) cert:
>
> Serial Number: 268238930 (0xffd0052)
> ...
> Validity
> Not Before: Dec 13 13:56:29 2019 GMT
> Not After : Dec  2 13:56:29 2021 GMT
>
> So, when installing the replica I got an older, expired cert in CS.cfg,
> but the certificate in nssdb is newer and valid.

I've fixed that manually on the new replica by copying the valid
certificate from LDAP into the CS.cfg files.

> Thanks for the "I need more context" ping. I looked at IPA bugs but
> nothing looked similar to this case. OTOH I would expect that far more
> people would also have this problem.

I'll see what the last replica looks like after the refresh when all
other replicas have been fixed.

Jochen

-- 
This space is intentionally left blank.
___
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-healthcheck with fresh replica

[Jochen Kellner via FreeIPA-users]

Rob Crittenden via FreeIPA-users 
writes:

> Jochen Kellner via FreeIPA-users wrote:
>> Topology:
>> freeipa1 + freeipa2: CentOS Linux release 7.8.2003 (Core) (upgrade from
>> older CentOS 7 releases)
>>  DNS, CA, KRA, AD trust
>>  freeipa1 is CA renewal master
>> 
>> ERROR: 
>> pki.server.healthcheck.meta.csconfig.DogtagCertsConfigCheck.kra_transport: 
>> Certificate 'transportCert cert-pki-kra' does not match the value of 
>> kra.transport.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
>> ERROR: 
>> pki.server.healthcheck.meta.csconfig.DogtagCertsConfigCheck.kra_storage: 
>> Certificate 'storageCert cert-pki-kra' does not match the value of 
>> kra.storage.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
>> ERROR: 
>> pki.server.healthcheck.meta.csconfig.DogtagCertsConfigCheck.kra_audit_signing:
>>  Certificate 'auditSigningCert cert-pki-kra' does not match the value of 
>> kra.audit_signing.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
>> ERROR: ipahealthcheck.dogtag.ca.DogtagCertsConfigCheck.transportCert 
>> cert-pki-kra: Certificate 'transportCert cert-pki-kra' does not match the 
>> value of ca.connector.KRA.transportCert in 
>> /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
>> WARNING: ipahealthcheck.ipa.dna.IPADNARangeCheck: No DNA range defined. If 
>> no masters define a range then users and groups cannot be created.
>> 
>> The warning is ok and I know how to deal with that. But for the errors
>> my expactation was that I shouldn't get any certificate errors on a new
>> replica. I've checked the certs/log (here for transportCert only):
>> 
>> args=['/usr/bin/certutil', '-d', 'sql:/etc/pki/pki-tomcat/alias', '-L', 
>> '-n', 'transportCert cert-pki-kra', '-a', '-f', 
>> '/etc/pki/pki-tomcat/alias/pwdfile.txt']
>> Process finished, return code=0
>> stdout=-BEGIN CERTIFICATE-
>> MIIDdDCCAlygAwIBAgIED/0AUjANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKDApK
>> ...
>> LjQX6mD/oR3hZnmE920+ABhk8QcJaRoi
>> -END CERTIFICATE-
>> 
>> And:
>> 
>> kra.transport.cert=
>> MIIDdDCCAlygAwIBAgIED/wABTANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKDApK
>> T0NIRU4uT1JHMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTcx
>>   ^first diff
>> [other changes...]
>> Some lines identical
>> [more differences].
>> 
>> So, ipa-healtcheck seems to be right. What's the best way to fix it? And
>> why is a fresh replica not clean?
>
> I think we'd need a bit more context. Is T0N a new line/entry, separate
> from MII? If so I'd run that through a base64 decoder to see what you
> get. I suspect it is a double-encoded cert. And if it is, what cert is it?

Yes, I think I need to tell more. In
/var/lib/pki/pki-tomcat/kra/conf/CS.cfg there is a line
kra.transport.cert=... This is one long line that I broke down like the 
output from certutil. There are parts in the certificate that are
identical, but others are different. I guess, it could be the same CSR,
but signed at a different time or something like that.  I'm not
proficient with certutil, but I'll try to have a deeper look into the
certificates.

In IPA I have four certificates for "IPA RA" - one (the oldest) revoked,
two are expired in 2017 and 2019 and one valid until next year.

The certificate in CS.cfg is expired:

Serial Number: 268173317 (0xffc0005)
...
Validity
Not Before: Dec 30 06:29:19 2017 GMT
Not After : Dec 20 06:29:19 2019 GMT
Subject: O = EXAMPLE.ORG, CN = KRA Transport Certificate

certutl has the correct (valid) cert:

Serial Number: 268238930 (0xffd0052)
...
Validity
Not Before: Dec 13 13:56:29 2019 GMT
Not After : Dec  2 13:56:29 2021 GMT

So, when installing the replica I got an older, expired cert in CS.cfg,
but the certificate in nssdb is newer and valid.

I've now checked /var/lib/pki/pki-tomcat/kra/conf/CS.cfg on all three
IPA servers, they all have the same expired kra.transport.cert= entry.

I see the certmonger tracking request only with "getcert list", not
ipa-getcert.

Request ID '20200606205724':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='transportCert 
cert-pki-kra',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='transportCert 
cert-pki-kra',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=EXAMPLE.ORG
subject: CN=KRA Transport Certificate,O=EXAMPLE.ORG
expires: 2021-12-02 14:56:29 CET
key usage: 
digitalSignature,nonRepudiation,k

[Freeipa-users] ipa-healthcheck with fresh replica

[Jochen Kellner via FreeIPA-users]

Hi,

I've been running IPA on CentOS 7 for some time on two servers with
integrated CA. With the release of CentOS 8.1 I tried upgrading with a
second replica - but scrapped that due to the problem with the wrong
samba libraries linked. Since no fix is in sight I thought about
migrating to Fedora 32 instead - which I've started yesterday.

Topology:
freeipa1 + freeipa2: CentOS Linux release 7.8.2003 (Core) (upgrade from
older CentOS 7 releases)
 DNS, CA, KRA, AD trust
 freeipa1 is CA renewal master

freeipa3: current Fedora 32 with the same services, ipa-replica-install
has chosen freeipa2 to replicate from. I've manually added an aditional
replica agreement betwen freeipa1 and freeipa3.

WebUI works, ipactl status is RUNNING, I get kerberos tickets, so I
guess we are most likely ok. Replication is also fine.

Before I start decomissioning freeipa2 I checked ipa-healthcheck:
$ ipa-healthcheck --output-type human --failures-only

ERROR: 
pki.server.healthcheck.meta.csconfig.DogtagCertsConfigCheck.kra_transport: 
Certificate 'transportCert cert-pki-kra' does not match the value of 
kra.transport.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
ERROR: pki.server.healthcheck.meta.csconfig.DogtagCertsConfigCheck.kra_storage: 
Certificate 'storageCert cert-pki-kra' does not match the value of 
kra.storage.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
ERROR: 
pki.server.healthcheck.meta.csconfig.DogtagCertsConfigCheck.kra_audit_signing: 
Certificate 'auditSigningCert cert-pki-kra' does not match the value of 
kra.audit_signing.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
ERROR: ipahealthcheck.dogtag.ca.DogtagCertsConfigCheck.transportCert 
cert-pki-kra: Certificate 'transportCert cert-pki-kra' does not match the value 
of ca.connector.KRA.transportCert in /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
WARNING: ipahealthcheck.ipa.dna.IPADNARangeCheck: No DNA range defined. If no 
masters define a range then users and groups cannot be created.

The warning is ok and I know how to deal with that. But for the errors
my expactation was that I shouldn't get any certificate errors on a new
replica. I've checked the certs/log (here for transportCert only):

args=['/usr/bin/certutil', '-d', 'sql:/etc/pki/pki-tomcat/alias', '-L', '-n', 
'transportCert cert-pki-kra', '-a', '-f', 
'/etc/pki/pki-tomcat/alias/pwdfile.txt']
Process finished, return code=0
stdout=-BEGIN CERTIFICATE-
MIIDdDCCAlygAwIBAgIED/0AUjANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKDApK
...
LjQX6mD/oR3hZnmE920+ABhk8QcJaRoi
-END CERTIFICATE-

And:

kra.transport.cert=
MIIDdDCCAlygAwIBAgIED/wABTANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKDApK
T0NIRU4uT1JHMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTcx
  ^first diff
[other changes...]
Some lines identical
[more differences].

So, ipa-healtcheck seems to be right. What's the best way to fix it? And
why is a fresh replica not clean?

Thanks for your help,
Jochen

-- 
This space is intentionally left blank.
___
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: ssh bash completion (no known_hosts)

[Jochen Kellner via FreeIPA-users]

Klaus Vink Slott via FreeIPA-users
 writes:

> But at the same time it is really annoying that to
> satisfy kerberos, I have to type the fqdn at the ssh prompt every time.

I have the following in my laptops ~/.ssh/config:

,
| CanonicalizeHostname always
| CanonicalDomains example.org
`

Jochen

-- 
This space is intentionally left blank.
___
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: Plans for integrating DHCP

[Jochen Kellner via FreeIPA-users]

Hello Ronald,

Ronald Wimmer via FreeIPA-users 
writes:

> are there any plans to integrate a DHCP server into FreeIPA. We have
> several environments where a lack of DHCP is a showstopper at the
> moment.

I have a (simple) script running that creates a configuration snippet
for dnsmasq from the MAC address in the host record and the
corresponding DNS entry. Works ok for my environment. Not bullet-proof
an doesn't for big sites (max records...)

#!/bin/bash

export LC_ALL="C.UTF-8"

out=/etc/dnsmasq.d/dynamic-hosts.conf
#out=/tmp/xxx
tmp=/etc/dnsmasq.d/.dynamic-hosts.conf.tmp

KRBPRINC="host/$(hostname --fqdn)@JOCHEN.ORG"

kinit -k $KRBPRINC

cat > $tmp <> ${tmp}.$$

ipa host-find --all --raw | awk '
	/fqdn:/ { ipstr=""; split($2,host,".") }
	/iface:/ { "getent ahostsv4 " host[1] "-" $2 | getline ipstr; split(ipstr, ip, " ");
		if ( ip[1] != "" ) 
			printf "dhcp-host=" $3 ",id:*," ip[1] "," host[1] "-" $2 ",24h\n"
		else
			printf "ERROR: no ip for host »%s« and interface »%s«.\n", host[1], $2 > "/dev/stderr" }' >> ${tmp}.$$

sort < ${tmp}.$$ > $tmp
rm -f ${tmp}.$$

kdestroy -A

if cmp -s $out $tmp; then
	rm -f $tmp ${tmp}.empty
else
if cmp -s ${tmp} ${tmp}.empty; then
rm -f ${tmp} ${tmp}.empty 
else
	mv $tmp $out
rm -f ${tmp}.empty 
	systemctl restart dnsmasq.service
fi
fi


Jochen

-- 
This space is intentionally left blank.
___
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: A Debian Head-Scratcher

[Jochen Kellner via FreeIPA-users]

"White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users"
 writes:

> SSSD does not seem to be the source of the glitch.  The sssd_nss.log says 
> that it successfully finds the user.
>
> All the error in /var/log/auth.log contain "pam_unix", so I tried
> adding "debug" to the end of every instance of "pam_unix/pam_unix.so"
> in /etc/pam.d, but it told me nothing new.
>
> Any other suggestions ?

Local users are authenticated by pam_unix, IPA users with pam_sss.
I do run a custom PAM configuration, because older IPA clients needed
that.

I dropped a special file in /usr/share/pam-configs and used that, but
that doesn't seem to be needed any longer.

So, pam_unix shouldn't be your problem when pam_sss is called also.
Rob's troubleshooting link should help you along.

Jochen

-- 
This space is intentionally left blank.
___
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-getcert and java certstore/keytool

[Jochen Kellner via FreeIPA-users]

Hi,

3. August 2017 03:03, "Fraser Tweedale via FreeIPA-users" 

schrieb:

> On Wed, Aug 02, 2017 at 11:11:09PM +0200, Jochen Hein via FreeIPA-users wrote:
>> I'm playing around with keycloak and wanted to use an SSL certificate
>> from IPA. I've looked around but didn't see any howto about using java
>> keytool with ipa-getcert. Has someone experience with it?
>> 
> Might as well jump straight to commands/logs :)

I did some more research yesterday and finally got a certificate
along the following lines:

- Generate a java keystore with keytool as described in the keycloak docs.
- Generate a csr with keytool and paste it into Freeipa.
- Got a certificate back from Freeipa.
- Import the certificate into keytool (again keycloak docs).

My first tries had the cert attributes wrong, but I think I now got it right,
but need to check with chrome to be sure. I'll post my steps later.

I was not successful in creating a certificate with ipa-getcert and
import the key into keytool. But I'll try to get something monitored by
certmonger - otherwise I'm sure the cert would expire... 

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