July 2017 - FreeIPA-users - Fedora mailing-lists

different failed auth times?
by Kat 20 Jul '17

20 Jul '17

Hi, If I have a simple pair of FreeIPA servers and one is showing different failed auth times for a user -- is this a good indication they are out of sync? Should I not see same failures on both? -k

3 3

keys for cert - how to get those?
by lejeczek 20 Jul '17

20 Jul '17

hello fallas those certs I see with: $ ipa cert-find is it possible to get private key(s) for a given cert? With means of (any)command line? many thanks. L.

2 3

Replica from RHEL6 7 fails to create CA with clone URI mismatch
by David Hendén 20 Jul '17

20 Jul '17

Hi all, I'm trying to set up a replica from RHEL6.9 FreeIPA 3.0.0 to RHEL7.3 RHEL 4.4.0. What I'm trying to achieve is an isolated FreeIPA 4.4 server that we could replace the original FreeIPA 3.0 infrastrcuture with. The way I'm doing this is: 1) prepare replica file on production ipa01 and copy to ipasync 2) install replica with CA on ipasync and then remove all connections to ipa01, ipa02 and ipa03 (which is the entire production infrastructure) 3) Upgrade schema on ipasync and upgrade to RHEL 6.9 (from RHEL 6.7) 4) Prepare replica file on ipasync and copy to ipa01 (a new clean installation in test that should later replace ipa01 in prod) 5) install replica with CA on ipa01 and then remove all connections to ipasync * Right now I'm failing at the create CA phase in step 5 with: [2/27]: configuring certificate server instance ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpDsKVFr' returned non-zero exit status 1 * I can see that it fails on the subsystem Clone URI in /var/log/ipareplica-install.log Installation failed: com.netscape.certsrv.base.BadRequestException: Clone URI does not match available subsystems: https://ipasync.xxx.com:443 Please check the CA logs in /var/log/pki/pki-tomcat/ca. 2017-07-11T15:24:52Z DEBUG stderr=pkispawn : WARNING ....... unable to validate security domain user/password through REST interface. Interface not available * To get more details I check the debug log for tomcat and find that it still tries to match against the old infrastructure and not the ipasync server: # cat /var/log/pki/pki-tomcat/ca/debug ... [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: len is 3 [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: hostname: <ipa01.xxx.com> [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: admin_port: <443> [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: hostname: <ipa02.xxx.com> [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: admin_port: <443> [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: hostname: <ipa03.xxx.com> [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: admin_port: <443> [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: === Subsystem Configuration === [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: SystemConfigService: validate clone URI: https://ipasync.xxx.com:443 [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: Clone URI does not match available subsystems: https://ipasync.xxx.com:443 * I validate this by checking the calist in getDomainXML: # wget --no-check-certificate https://ipasync.xxx.com:443/ca/admin/ca/getDomainXML # cat getDomainXML | xmllint --format - ... <CAList> <CA> <DomainManager>TRUE</DomainManager> <SubsystemName>pki-cad</SubsystemName> <Clone>FALSE</Clone> <UnSecurePort>80</UnSecurePort> <SecureEEClientAuthPort>443</SecureEEClientAuthPort> <SecureAdminPort>443</SecureAdminPort> <SecureAgentPort>443</SecureAgentPort> <SecurePort>443</SecurePort> <Host>ipa01.xxx.com</Host> </CA> <CA> <SubsystemName>pki-cad</SubsystemName> <Clone>TRUE</Clone> <DomainManager>TRUE</DomainManager> <SecureEEClientAuthPort>443</SecureEEClientAuthPort> <UnSecurePort>80</UnSecurePort> <SecureAdminPort>443</SecureAdminPort> <SecureAgentPort>443</SecureAgentPort> <SecurePort>443</SecurePort> <Host>ipa02.xxx.com</Host> </CA> <CA> <SubsystemName>pki-cad</SubsystemName> <Clone>TRUE</Clone> <DomainManager>TRUE</DomainManager> <SecureEEClientAuthPort>443</SecureEEClientAuthPort> <UnSecurePort>80</UnSecurePort> <SecureAdminPort>443</SecureAdminPort> <SecureAgentPort>443</SecureAgentPort> <SecurePort>443</SecurePort> <Host>ipa03.xxx.com</Host> </CA> <SubsystemCount>3</SubsystemCount> </CAList> ... Why does it still have the old ipa servers and why is not ipasync included? Am I doing something wrong here, for example do I need to manually add ipasync to the pki-cad list of CAs? Best regards, -David -- David Hendén ITF +46736330916 david.henden(a)itf.se

4 3

Re: Freeipa and Google Cloud Directory Sync (GCDS) password sync failing
by David Harvey 20 Jul '17

20 Jul '17

FWIW this was entirely down to a problem in the GCDS tool (or my use of it). Although GCDS bundles it's own JRE and keystore, it had defaulted to using the system JRE and keystore. Adding "-Djavax.net.ssl.trustStore=/opt/GoogleCloudDirSync/jre/lib/security/cacerts" to config-manager.vmoptions (in the GCDS base directory) got it working (after adding the ca cert). I imagine using the GCDS documented method of adding a CA (but referencing the system keystore) would have a similar result.

1 0

Kerberized NFS for system users
by Anton Semjonov 19 Jul '17

19 Jul '17

Hello everyone! I am trying to setup an NFS export with sec=krb5p on one machine and make it accessible to a system user ('git' in this case) on another. I'd like to put GitLab backups on my ZFS array via NFS, to be more specific. All machines in my little homelab are based on CentOS 7.3.1611 and I use two replicated FreeIPA servers with what I believe to be the latest release available on CentOS: 4.4.0. Both the storage server and the GitLab server are enrolled hosts in my realm. After enrolling both machines with ipa-client-install and installing @File\ and\ Storage\ Server on one and @Network\ File\ System\ Client on the other, I ran ipa-client-automount on both, as I read somewhere that it sets up neccessary configuration files for identity mapping? I also found a thread on this mailinglist, about a usecase of Apache accessing a /var/www directory via kerberized NFS. I believe my usecase is very similar and I feel like I am very close to a solution. But I just don't understand where things go wrong: In this particular case the 'git' user on both machines has different UIDs. It was created during the installation of GitLab on the client but the UID was already occupied by 'softhsm private keys owner' on the server. Thus I created a system user manually, which has a different UID though. For the sake of troubleshooting I also tried all the following steps with the Apache user, which has UID 48 on both machines - the result was the same. As this is not an actual user in my realm, I first created a service principal of the form git/$HOSTNAME@REALM (or apache/... for that matter). I then used ipa-getkeytab to create a keytab in /var/lib/gssproxy/clients/$UID.keytab for gssproxy to find. That worked nicely as in: The user automagically got access to the mounted NFS share while a krb5cc_$UID was created in the directory mentioned above. After switching users with su, I can navigate through the mount - as long as all the folders have 755 permissions. A folder with 700 permissions and owner 'git' is correctly displayed as being owned by 'git' on the client - yet I cannot access it! When I create a file or folder in a folder with public permissions (777), the owner of the newly created file is 'nfsnobody'. I also tried setting up a static mapping in /etc/idmapd.conf on both the server and client: mapping the service principal to user 'git'. The effect was the client displaying the folder being owned by 'nobody' - whoops. Doing all the above steps with an actual user in the realm works fine. Either with the automagic method through gssproxy or by getting a ticket with kinit first: I can access a folder with 700 permissions and files are created with the correct owner, etc. Is there any critical step that I missed? I feel like I am very close .. I'd be thankful for any hints. Cheers, Anton

2 3

can't upgrade IPA because of certificate alias problem
by Charles Hedrick 19 Jul '17

19 Jul '17

I’ve installed ipa. Originally I did the default install, without DNS. I then updated to a commercial cert. Notes at the end. I just did a yum update. isa-upgrade failed with the following error: 017-07-12T19:23:39Z DEBUG stderr= 2017-07-12T19:23:44Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2017-07-12T19:23:45Z DEBUG Starting external process 2017-07-12T19:23:45Z DEBUG args=/usr/bin/certutil -d /etc/dirsrv/slapd-CS-RUTGERS-EDU -L -n Server-Cert -a 2017-07-12T19:23:45Z DEBUG Process finished, return code=255 2017-07-12T19:23:45Z DEBUG stdout= 2017-07-12T19:23:45Z DEBUG stderr=certutil: Could not find cert: Server-Cert : PR_FILE_NOT_FOUND_ERROR: File not found When I do /usr/bin/certutil -d /etc/dirsrv/slapd-CS-RUTGERS-EDU -L I find that there is no Server-Cert alias. Instead Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE C,, CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US C,, CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US C,, ipaCert u,u,u CS.RUTGERS.EDU IPA CA CT,C,C CN=krb2.cs.rutgers.edu,OU=SAS,O="Rutgers, The State University of New Jersey",STREET=43 College Avenue,STREET=Room 226A,L=New Brunswick,ST=NJ,postalCode=08901,C=US u,u,u Any idea how to fix this? Can I safely rename the last entry to be Server-Cert? Can I safely run isa-server-upgrade again to make sure it works? I have a replicate. Upgrade for it worked fine, but CA services aren’t installed on it. —————— upgrading to commercial cert: When you set up IPA it will generate its own certificate. It will be used for both ldap and http. A CA cert goes into /etc/ipa/ca.cert. In the long run you want to use a commercial certificate. I got back from the certificate people a key, a cert, and a CA chain. Installing them was a hair-raising experience. Note that on the backup, the intermediates are already there, because they're copied from the primary. Hence you can go directly to ipa-server-certinstall. This is probably true for renewal as well. • Before you can install the actual cert, you need to install all the CA certificates for the chain. • Take apart the intermediate certificates. If you look at the file you'll see it has 3 obvious sections. • Use openssl x509 --in FILE --text to look at them • Starting at the top level, install each one using ipa-cacert-manage -p PASSWORD -n NICKNAME -t C,, install FILE ; PASSWORD is the admin password for the system. ; NICKNAME is a word you pick to identify the CA. ; FILE is the file with the data • ipa-certupdate ; this actually updates the CA database with the new certs • ipa-server-certinstall -w -d mysite.key mysite.crt, i.e. the files with the key and the actual cert for this system • systemctl restart httpd.service This will probably fail. In /etc/httpd/conf.d/nss.conf, it adds a line like NSSNickname "CN=krb1.cs.rutgers.edu,OU=SAS,O="Rutgers, The State University of New Jersey",STREET=43 College Avenue,STREET=\ Room 226A,L=New Brunswick,ST=NJ,postalCode=08901,C=US" Unfortunately this is a syntax error. To fix it, add \ before the "'s inside the string. Make sure you can restart httpd.service cleanly. I do *not* recommend rebooting the system until that's fixed. Now systemctl restart dirsrv(a)CS-RUTGERS-EDU.service

3 3

Update signing certificate
by Jeff Fouchard 19 Jul '17

19 Jul '17

We are in the process of switching to using an external CA. We have successfully gone through he process and indeed the Web UI now shows the expected certificate chain. However when we issue certificates to our clients downstream they are using a signing certificate that was not issued by the new external CA. I've tried to find in the documentation how that gets set, but seem to be at a loss. Can anyone point me in the correct direction? Thanks! Jeff

4 5

ipa-server-4.4.0-14.el7.centos.7.x86_64 - 389 dirsrv will not start
by email＠ml.jacobdevans.com 19 Jul '17

19 Jul '17

Hey Guys, Was having some strange issues and found one of the dirsrv services crashed, I can't say this is the only time this has happened but usually it starts manually or on reboot. Any ideas on this one? Let me know if you need more info. Thanks as always! -Jake # /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-IPA-EXAMPLE-COM/ -i /tmp/pid -d 0 [11/Jul/2017:16:05:19.863080375 -0400] /etc/dirsrv/slapd-IPA-EXAMPLE-COM/dse.ldif: nsslapd-maxdescriptors: nsslapd-maxdescriptors: invalid value "8192", maximum file descriptors must range from 1 to 4096 (the current process limit). Server will use a setting of 4096. [11/Jul/2017:16:05:20.678367302 -0400] Config Warning: - nsslapd-maxdescriptors: invalid value "8192", maximum file descriptors must range from 1 to 4096 (the current process limit). Server will use a setting of 4096. [11/Jul/2017:16:05:20.884727597 -0400] SSL alert: Sending pin request to SVRCore. You may need to run systemd-tty-ask-password-agent to provide the password. [11/Jul/2017:16:05:20.889448314 -0400] SSL alert: Security Initialization: Enabling default cipher set. [11/Jul/2017:16:05:20.891303974 -0400] SSL alert: Configured NSS Ciphers [11/Jul/2017:16:05:20.892784699 -0400] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled [11/Jul/2017:16:05:20.894190246 -0400] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [11/Jul/2017:16:05:20.896148555 -0400] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [11/Jul/2017:16:05:20.897649444 -0400] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [11/Jul/2017:16:05:20.898782790 -0400] SSL alert: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled [11/Jul/2017:16:05:20.900295051 -0400] SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [11/Jul/2017:16:05:20.901793904 -0400] SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [11/Jul/2017:16:05:20.903844512 -0400] SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [11/Jul/2017:16:05:20.905806426 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled [11/Jul/2017:16:05:20.907659164 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [11/Jul/2017:16:05:20.909288663 -0400] SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [11/Jul/2017:16:05:20.910794086 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [11/Jul/2017:16:05:20.912176687 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [11/Jul/2017:16:05:20.913867463 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [11/Jul/2017:16:05:20.915299928 -0400] SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [11/Jul/2017:16:05:20.916799631 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [11/Jul/2017:16:05:20.918053176 -0400] SSL alert: TLS_RSA_WITH_AES_256_GCM_SHA384: enabled [11/Jul/2017:16:05:20.919124838 -0400] SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [11/Jul/2017:16:05:20.920174353 -0400] SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [11/Jul/2017:16:05:20.922796130 -0400] SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [11/Jul/2017:16:05:20.924205153 -0400] SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [11/Jul/2017:16:05:20.925692536 -0400] SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [11/Jul/2017:16:05:20.927319888 -0400] SSL alert: TLS_AES_128_GCM_SHA256: enabled [11/Jul/2017:16:05:20.928818181 -0400] SSL alert: TLS_CHACHA20_POLY1305_SHA256: enabled [11/Jul/2017:16:05:20.931222826 -0400] SSL alert: TLS_AES_256_GCM_SHA384: enabled [11/Jul/2017:16:05:20.932804077 -0400] SSL alert: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256: enabled [11/Jul/2017:16:05:20.934170837 -0400] SSL alert: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled [11/Jul/2017:16:05:20.935755841 -0400] SSL alert: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled [11/Jul/2017:16:05:20.946592234 -0400] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [11/Jul/2017:16:05:20.948508895 -0400] 389-Directory/1.3.5.10 B2017.145.2037 starting up [11/Jul/2017:16:05:20.964016533 -0400] default_mr_indexer_create: warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match [11/Jul/2017:16:05:20.974478684 -0400] WARNING: changelog: entry cache size 2097152 B is less than db size 78987264 B; We recommend to increase the entry cache size nsslapd-cachememsize. [11/Jul/2017:16:05:20.977222708 -0400] Detected Disorderly Shutdown last time Directory Server was running, recovering database. Segmentation fault Thank You, Jacob D. Evans Cloud Consultant 717.417.8324 [ http://twitter.jacobdevans.com/ ] [ http://facebook.jacobdevans.com/ ] [ http://www.jacobdevans.com/ ] [ http://linkedin.jacobdevans.com/ ] [ mailto:sig-contact@jacobdevans.com ] [ http://serverfault.com/users/200560/jacob-evans ] [ https://github.com/jakedevans ] [ https://keybase.io/jacobdevans ] From: "Jake" <email(a)ml.jacobdevans.com> To: "freeipa-users" <freeipa-users(a)redhat.com> Sent: Tuesday, July 11, 2017 4:08:42 PM Subject: ipa-server-4.4.0-14.el7.centos.7.x86_64 - 389 dirsrv will not start Was having some strange issues and found one of the dirsrv services crashed, I can't say this is the only time this has happened but usually it starts manually or on reboot. Any ideas on this one? Let me know if you need more info. Thanks as always! -Jake # /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-IPA-EXAMPLE-COM/ -i /tmp/pid -d 0 [11/Jul/2017:16:05:19.863080375 -0400] /etc/dirsrv/slapd-IPA-EXAMPLE-COM/dse.ldif: nsslapd-maxdescriptors: nsslapd-maxdescriptors: invalid value "8192", maximum file descriptors must range from 1 to 4096 (the current process limit). Server will use a setting of 4096. [11/Jul/2017:16:05:20.678367302 -0400] Config Warning: - nsslapd-maxdescriptors: invalid value "8192", maximum file descriptors must range from 1 to 4096 (the current process limit). Server will use a setting of 4096. [11/Jul/2017:16:05:20.884727597 -0400] SSL alert: Sending pin request to SVRCore. You may need to run systemd-tty-ask-password-agent to provide the password. [11/Jul/2017:16:05:20.889448314 -0400] SSL alert: Security Initialization: Enabling default cipher set. [11/Jul/2017:16:05:20.891303974 -0400] SSL alert: Configured NSS Ciphers [11/Jul/2017:16:05:20.892784699 -0400] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled [11/Jul/2017:16:05:20.894190246 -0400] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [11/Jul/2017:16:05:20.896148555 -0400] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [11/Jul/2017:16:05:20.897649444 -0400] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [11/Jul/2017:16:05:20.898782790 -0400] SSL alert: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled [11/Jul/2017:16:05:20.900295051 -0400] SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [11/Jul/2017:16:05:20.901793904 -0400] SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [11/Jul/2017:16:05:20.903844512 -0400] SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [11/Jul/2017:16:05:20.905806426 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled [11/Jul/2017:16:05:20.907659164 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [11/Jul/2017:16:05:20.909288663 -0400] SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [11/Jul/2017:16:05:20.910794086 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [11/Jul/2017:16:05:20.912176687 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [11/Jul/2017:16:05:20.913867463 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [11/Jul/2017:16:05:20.915299928 -0400] SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [11/Jul/2017:16:05:20.916799631 -0400] SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [11/Jul/2017:16:05:20.918053176 -0400] SSL alert: TLS_RSA_WITH_AES_256_GCM_SHA384: enabled [11/Jul/2017:16:05:20.919124838 -0400] SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [11/Jul/2017:16:05:20.920174353 -0400] SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [11/Jul/2017:16:05:20.922796130 -0400] SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [11/Jul/2017:16:05:20.924205153 -0400] SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [11/Jul/2017:16:05:20.925692536 -0400] SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [11/Jul/2017:16:05:20.927319888 -0400] SSL alert: TLS_AES_128_GCM_SHA256: enabled [11/Jul/2017:16:05:20.928818181 -0400] SSL alert: TLS_CHACHA20_POLY1305_SHA256: enabled [11/Jul/2017:16:05:20.931222826 -0400] SSL alert: TLS_AES_256_GCM_SHA384: enabled [11/Jul/2017:16:05:20.932804077 -0400] SSL alert: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256: enabled [11/Jul/2017:16:05:20.934170837 -0400] SSL alert: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled [11/Jul/2017:16:05:20.935755841 -0400] SSL alert: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled [11/Jul/2017:16:05:20.946592234 -0400] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [11/Jul/2017:16:05:20.948508895 -0400] 389-Directory/1.3.5.10 B2017.145.2037 starting up [11/Jul/2017:16:05:20.964016533 -0400] default_mr_indexer_create: warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match [11/Jul/2017:16:05:20.974478684 -0400] WARNING: changelog: entry cache size 2097152 B is less than db size 78987264 B; We recommend to increase the entry cache size nsslapd-cachememsize. [11/Jul/2017:16:05:20.977222708 -0400] Detected Disorderly Shutdown last time Directory Server was running, recovering database. Segmentation fault

2 1

docker container user no matching entries in passwd file
by Thomas Lau 19 Jul '17

19 Jul '17

docker-host# docker run --user=testaccount1 -d -p 9001:9001 e7b263ac54e2 990c220ccb30b5012e7e5aa45f7e9345098cdb867328302daff567474055de02 docker: Error response from daemon: linux spec user: unable to find user testaccount1: no matching entries in passwd file. docker-host# getent passwd testaccount1 testaccount1:*:1218400025:1218400025:test account:/local/home/testaccount1:/bin/bash anyone know how exactly can I run docker contain on accounts which is in FreeIPA? docker-host is Ubuntu, running sssd. -- Thomas Lau Director of Infrastructure Tetrion Capital Limited Direct: +852-3976-8903 Mobile: +852-9323-9670 Address: Suite 2716, Two IFC, Central, Hong Kong

3 2

HBAC rules / ssh keys for AD users not working right away
by bogusmaster＠o2.pl 18 Jul '17

18 Jul '17

Hi all, I have set up trust between FreeIPA and AD. Users from AD domain can successfully log into the linux boxes when I have allow_all rule enabled. However, when I try to achieve something more fancy, like assigning set of users to a custom group (firstly external, then the posix one) or make it possible for AD users to use ssh public key authentication via Default Trust View user settings override, FreeIPA behaves in slightly nondeterministic way. It manifests itself in a couple of ways: - users that I uploaded SSH keys for can't use them right away. Sometimes it is a matter of minutes, sometimes it is a matter of hours for the ssh public keys to work. I observed that when I add a couple of keys, then whenever one ssh public key starts working for one user, it works for all of them. - the same as above applies to AD users that are added to a group which later on is used in HBAC rule definition. When I add a user to this group, he/she can't log in straight away but it takes some time to propagate. - and last but not least: when I delete a user who can successfully log into a Linux box from a group which is used in HBAC rule definition, he/she can still log in to that box. To make things more awkward, user can access one client machine as if they wasn't deleted from the group whereas they can't access other client machine and receives "Connection closed by UNKNOWN" response upon ssh connection establishment (which is desired in both Linux machines). I tried to clear sssd cache by issuing sss_cache -E and restarted sssd daemon on Linux machine which is affected by that behaviour, but to no avail. Can someone please point me to what I can do to troubleshoot this further and make changes applied to IPA server be visible right away? Many thanks, Bart

3 24

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users July 2017