I and Stanislav have been setting up Travis CI for the
repository. We now run docker build operations for pull requests
and commits, and I've been trying to add docker run tests as well.
Example Travis build
seems to pass on CentOS and rawhide images but fails on other Fedoras.
All the failures are in the
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
[1/28]: configuring certificate server instance
[error] RuntimeError: CA configuration failed.
step. I remember that due to the way systemd was handling KEYRING
operations, seccomp:unconfined was one of the things that has been
causing issues in our tests on Fedora hosts. Running
in Travis CI shows that it's running 17.09.0-ce and there are no
Security Options listed, unlike on my Fedora 28's
docker-1.13.1-59.gitaf6b32b.fc28.x86_64 which has
Are there people around with Ubuntu knowledge who could check what
the docker 17.09.0-ce behaviour on that system is and if seccomp can
somehow be tweaked?
Senior Principal Software Engineer, Security Engineering, Red Hat
I have a question about the best pratice use of freeipa with trust AD
and/or sync relationship from winsync users.
to set up an smb file sharing service via samba, would you advise to
integrate it in the IPA realm or in the AD domain?
Both are possible, but why one more than the other? in terms of file
access performance (metadata, acl ,etc....) managed via the smb protocol
isn't there a drawback related to samba in royaume ipa to serve users
who use a windows client?
do you have the same response arguments in the case of a sync between AD
I have a synology NAS which hosts some SMB shares on my network. I would
like to be able to use FreeIPA as the LDAP provider it checks against for
authenticating these shares. I have a system user that I created in
FreeIPA for this purpose.
I configured the NAS to connect to my FreeIPA server for LDAP, but I get a
message about a failure to access some users NT passwords and how the Samba
service may not work for these users. It also says it could be either a
lack of NT passwords for the users or insufficient privileges to access
them. After chatting with Synology support they wanted me to enable CIFS
plaintext password authentication. However, if I select that option it
given me a warning about the share not being able to be the remote mount
target of CIFS anymore due to SMB being set to v1 only and disabling the
SMB related Bonjour service. If the system user doesn't have the needed
privileges, how can I fix that since I can't enroll the NAS?
BYU Dept. of Chemistry and Biochemistry
I changed password AD users.
I can't login on ipa servers with new password, but can - with old. Why?
I tried restart ipa services and reinitializing trust. but it didn't help.
С уважением, Николай.
I've got a system (probably more than one) where I've got clients who
aren't able to bring up SSSD due to this error, as seen in "journalctl -xe".
I've tried unenrolling & re-enrolling. I've tried unenrolling,
uninstalling, reinstalling ipa-client, and re-enrolling. I've tried
unenrolling, deleting the host records from the IPA server, then
re-enrolling. I've tried reinstalling SSSD. None have changed the
behavior at all.
Does anyone know what this error refers to or is caused by?
Founder, Damascus Products, LLC
855-644-2783 <tel:855-644-2783> | bret(a)wrapbuddies.co
10332 Main St Suite 319 Fairfax, VA 22030
I would like to use public key authentication in my FreeIPA setup for the users coming from the AD domain. I have everything set up correctly, public key authentication works great aside from one edge case that may render this setup unacceptable. When I lock an AD account (I test this by logging in with the wrong password more than allowed amount of times) user in question still can access FreeIPA managed hosts via public key authentication.
According to the information I found regarding this behaviour - https://bugzilla.redhat.com/show_bug.cgi?id=973451 - this is a desired behaviour (it's not a bug, it's a feature). Still, it's not the configuration I am happy about :).
Has anything changed since this bug was closed?
Is there a way FreeIPA supports preventing users who are for whatever reason locked in AD from accessing FreeIPA-managed hosts?
If this is not currently supported by default, maybe someone could point me to a way I could implement this myself? I am thinking of checking if the user is locked in AD, hopefully by looking at his/hers ldap attributes in the 389 ds server in FreeIPA if such attributes exist, then removing any public keys that are present in the Default Trust View for this user. At this point I do not know it is possible, it is just an idea.
I would really appreciate your help.
In the final step of upgrading my freeIPA servers to fedora26/freeIPA 4.4.4, I removed the current demoted the current renewal master, and promoted a CA (sif) as new renewal master, following instructions from < https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#R... >.
Since then, pki-tomcatd will not start, here's an excerpt of /var/log/pki/pki-tomcat/ca/debug :
[17/Jul/2018:15:34:57][localhost-startStop-1]: CMSEngine: ready to init id=dbs
[17/Jul/2018:15:34:57][localhost-startStop-1]: DBSubsystem: init() mEnableSerialMgmt=true
[17/Jul/2018:15:34:57][localhost-startStop-1]: Creating LdapBoundConnFactor(DBSubsystem)
[17/Jul/2018:15:34:57][localhost-startStop-1]: LdapBoundConnFactory: init
[17/Jul/2018:15:34:57][localhost-startStop-1]: LdapBoundConnFactory:doCloning true
[17/Jul/2018:15:34:57][localhost-startStop-1]: LdapAuthInfo: init()
[17/Jul/2018:15:34:57][localhost-startStop-1]: LdapAuthInfo: init begins
[17/Jul/2018:15:34:57][localhost-startStop-1]: LdapAuthInfo: init ends
[17/Jul/2018:15:34:57][localhost-startStop-1]: init: before makeConnection errorIfDown is true
[17/Jul/2018:15:34:57][localhost-startStop-1]: makeConnection: errorIfDown true
[17/Jul/2018:15:34:57][localhost-startStop-1]: TCP Keep-Alive: true
[17/Jul/2018:15:34:57][localhost-startStop-1]: SSLClientCertificateSelectionCB: Setting desired cert nickname to: subsystemCert cert-pki-ca
[17/Jul/2018:15:34:57][localhost-startStop-1]: LdapJssSSLSocket: set client auth cert nickname subsystemCert cert-pki-ca
[17/Jul/2018:15:34:57][localhost-startStop-1]: SSLClientCertificatSelectionCB: Entering!
[17/Jul/2018:15:34:57][localhost-startStop-1]: SSLClientCertificateSelectionCB: returning: null
[17/Jul/2018:15:34:57][localhost-startStop-1]: SSL handshake happened
Could not connect to LDAP server host sif.quartzbio.com port 636 Error netscape.ldap.LDAPException: Authentication failed (48)
I found this very useful blog: < https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tom... > and checked all the steps.
From what I checked:
- my certificates are valid
- there was two userCertificate for pkidbuser, one expired. I removed it using Apache Directory Studio
- the pkidbuser certificate match the one from /etc/pki/pki-tomcat/alias
One possibly relevant info: the previous renewal master/CA was the main DNS, it is no longer running since I was about to recreate it when I discovered that the pki-tomcatd was not running when I tried to execute ipa-prepare-replicate.
I would be grateful if you could help me or guide me debugging this.
Maximum username length: 32
Home directory base: /home
Default shell: /bin/bash
Default users group: ipausers
Default e-mail domain: example.com
Search time limit: 2
Search size limit: 100
User search fields: uid,givenname,sn,telephonenumber,ou,title
Group search fields: cn,description
Enable migration mode: FALSE
Certificate Subject base: O=QUARTZBIO.COM
Password Expiration Notification (days): 4
Password plugin features: AllowNThash
SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023
Default PAC types: nfs:NONE, MS-PAC
IPA masters: amora.example.com, sif.example.com
IPA CA servers: amora.example.com, sif.example.com
IPA NTP servers: amora.example.com, sif.example.com
IPA CA renewal master: sif.example.com
grep internaldb.ldap /etc/pki/pki-tomcat/ca/CS.cfg
sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca'
Version: 3 (0x2)
Serial Number: 86 (0x56)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=QUARTZBIO.COM"
Not Before: Wed May 31 15:49:31 2017
Not After : Tue May 21 15:49:31 2019
Subject: "CN=CA Subsystem,O=QUARTZBIO.COM"
sudo grep internal /var/lib/pki/pki-tomcat/conf/password.conf | cut -d= -f2 > /tmp/pwdfile.txt
sudo certutil -K -d /etc/pki/pki-tomcat/alias -f /tmp/pwdfile.txt -n 'subsystemCert cert-pki-ca'
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
< 0> rsa 4c9dcd686df2a289ef1bcd21d2dfb195a0d7bc9c subsystemCert cert-pki-ca
sudo cat /etc/dirsrv/slapd-IPADOMAIN-COM/certmap.conf
certmap ipaca CN=Certificate Authority,O=QUARTZBIO.COM
ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca description
description: 2;86;CN=Certificate Authority,O=QUARTZBIO.COM;CN=CA Subsystem,O=Q
sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' | grep Serial
Serial Number: 86 (0x56)
getcert list | grep "expires\|status\|subject" | perl -pe 's/quartzbio/example/ig'
expires: 2020-07-13 13:44:48 CEST
subject: CN=CA Audit,O=example.COM
expires: 2019-05-21 17:50:42 CEST
subject: CN=OCSP Subsystem,O=example.COM
expires: 2019-05-21 17:50:01 CEST
subject: CN=CA Subsystem,O=example.COM
expires: 2019-05-21 17:49:31 CEST
subject: CN=Certificate Authority,O=example.COM
expires: 2035-07-09 11:41:54 CEST
expires: 2020-07-02 16:57:18 CEST
expires: 2020-07-13 13:44:52 CEST
subject: CN=IPA RA,O=example.COM
expires: 2019-05-21 17:50:10 CEST
Hi IPA Users,
What is the status of the IPA integration with Kerberos utilities such as kadmin (kadmin.local) and kdb5_util? Can they be used or are they not supported. If not supported maybe they should report an error or warning.
It seems setting a user's password expiration with kadmin works in the short term, but is later overwritten perhaps by multi-master replication? I was testing password expiration and I set a value using kadmin modprinc yesterday and noticed today that the value has reverted back to what it was earlier. As an aside using ipa user-mod --setattr=krbPasswordExpiration=20180715011529Z is clumsy and admin user doesn't even have the privilege to execute it successfully. LDAP modify with directory manager has the privilege, but LDIF is even more clumsy. With kadmin.local modprinc I can use -pwexpire 1day.
Also, importing an existing database of principals with password hashes would make migration from a standalone KDC much less painful. Any chance that feature is added at some point? Looks like one challenge might be what appears to be the 389 directory server storing user passwords in two separate fields (userPassword and krbPrincipalKey), which are presumably hashed differently.