different failed auth times?
by Kat
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
6 years, 9 months
keys for cert - how to get those?
by lejeczek
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.
6 years, 9 months
Replica from RHEL6 7 fails to create CA with clone URI mismatch
by David Hendén
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
6 years, 9 months
Re: Freeipa and Google Cloud Directory Sync (GCDS) password sync failing
by David Harvey
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.
6 years, 9 months
Kerberized NFS for system users
by Anton Semjonov
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
6 years, 9 months
can't upgrade IPA because of certificate alias problem
by Charles Hedrick
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
6 years, 9 months
Update signing certificate
by Jeff Fouchard
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
6 years, 9 months
ipa-server-4.4.0-14.el7.centos.7.x86_64 - 389 dirsrv will not start
by email＠ml.jacobdevans.com
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
6 years, 9 months
docker container user no matching entries in passwd file
by Thomas Lau
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
6 years, 9 months
HBAC rules / ssh keys for AD users not working right away
by bogusmaster＠o2.pl
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
6 years, 9 months
