Re: [Freeipa-users] How to turn off RC4 in 389ds???
That did it. Thank you. On Thu, Sep 24, 2015 at 12:59 AM, Martin Kosek <mko...@redhat.com> wrote: > Hello Michael, > > It is possible that this problem comes from obsolete package in the > mkosek/freeipa COPR repo, which was fixed in Fedora/RHEL, but not there. > > Can you please try to update the 389-ds-base from > > https://copr.fedoraproject.org/coprs/mkosek/freeipa/ > > ? I rebuilt the latest F21 389-ds-base to the repo, there were some > related fixes. > > Thanks, > Martin > > On 09/23/2015 05:50 PM, Michael Lasevich wrote: > > No difference. It is as if this setting is being overwritten somewhere > deep > > in 389ds, because the "error" log correctly reflects the changes, but the > > actual process does not. (and yes, I verified that the process actually > > shuts down and start up again when I restart it) > > > > ldapsearch -x -D "cn=directory manager" -W -b "cn=encryption,cn=config" > > # encryption, config > > dn: cn=encryption,cn=config > > objectClass: top > > objectClass: nsEncryptionConfig > > cn: encryption > > nsSSLSessionTimeout: 0 > > nsSSLClientAuth: allowed > > sslVersionMin: TLS1.0 > > nsSSL3Ciphers: +all > > allowWeakCipher: off > > nsSSL3: off > > nsSSL2: off > > ... (skipping nssslenabledciphers's) ... > > nsTLS1: on > > sslVersionMax: TLS1.2 > > > > SLAPD error log got longer: > > > > SSL Initialization - Configured SSL version range: min: TLS1.0, max: > TLS1.2 > > [23/Sep/2015:09:37:28 -0600] - SSL alert: Configured NSS Ciphers > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > > [23/Sep/2015:09:37:28 -0600] - SSL alert: > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > > [23/Sep/2015:09:37:29 -0600] - SSL alert: > > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > > [23/Sep/2015:09:37:29 -0600] - SS
[Freeipa-users] OTP unstable/non functional after upgrade?
Ok, something odd happened I would love some feedback/ideas on: We had 4.1.2 running on Fedora that we used for, among other things, OTP authentication. I have just upgraded these to CentOS 7 with 4.1.4 running and our OTP setup suddenly became very unstable. Things that have changed during upgrade that may be contributing to this: * OS went from Fedora to CentOS7 * Version of the IPA code went from 4.1.2 to 4.1.4 * Anonymous LDAP access was disabled * Directory Manager password was changed (to solve unrelated problem) * An attempt to reduce number of supported ciphers for LDAPs (Port 636) * Ditto for SSL port for apache. Symptoms: * Upon even before upgrade was completed (one server, the one auth was being attempted against, was still running old code) - it would not authenticate LDAP connection using password+otp format. Password alone worked fine. * After update I tried to login to IPA UI using password+otp - it was not working. So I logged in without otp and added a new OTP code. After that suddenly I could use both the old and the new token generators to login but not all the time... new one was more consistent, but failed from time to time too. This is happening to at least one other user - so I think the issue is not associated with user account. * At no time sync token UI worked. Always says wrong/invalid token. I really need this to work - any ideas/suggestions would be appreciated. -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] How to turn off RC4 in 389ds???
Yes, I am talking about 389ds as is integrated in FreeIPA (would be silly to post completely non-IPA questions to this list...). I am running FreeIPA 4.1.4 on CentOS 7.1 and RC4 is enabled on port 636 no matter what I do. I am running "CentOS Linux release 7.1.1503 (Core)" Relevant Packages: freeipa-server-4.1.4-1.el7.centos.x86_64 389-ds-base-1.3.3.8-1.el7.centos.x86_64 nss-3.19.1-5.el7_1.x86_64 openssl-1.0.1e-42.el7.9.x86_64 LDAP setting (confirmed that in error.log there is no menition of RC4 in list of ciphers): nsSSL3Ciphers: -rc4,-rc4export,-rc2,-rc2export,-des,-desede3,-rsa_rc4_128_md5,-rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,+rsa_fips_3des_sha,+fips_3des_sha,-rsa_fips_des_sha,-fips_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,-tls_rsa_export1024_with_rc4_56_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_des_cbc_sha,-rsa_des_56_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-dhe_dss_des_sha,+dhe_dss_3des_sha,-dhe_rsa_des_sha,+dhe_rsa_3des_sha,+tls_rsa_aes_128_sha,+rsa_aes_128_sha,+tls_dhe_dss_aes_128_sha,+tls_dhe_rsa_aes_128_sha,+tls_rsa_aes_256_sha,+rsa_aes_256_sha,+tls_dhe_dss_aes_256_sha,+tls_dhe_rsa_aes_256_sha,-tls_dhe_dss_1024_rc4_sha,-tls_dhe_dss_rc4_128_sha Slapd "error" log showing no ciphersuites supporting RC4: [23/Sep/2015:08:51:04 -0600] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [23/Sep/2015:08:51:04 -0600] - SSL alert: Cipher suite fortezza is not available in NSS 3.16. Ignoring fortezza [23/Sep/2015:08:51:04 -0600] - SSL alert: Cipher suite fortezza_rc4_128_sha is not available in NSS 3.16. Ignoring fortezza_rc4_128_sha [23/Sep/2015:08:51:04 -0600] - SSL alert: Cipher suite fortezza_null is not available in NSS 3.16. Ignoring fortezza_null [23/Sep/2015:08:51:04 -0600] - SSL alert: Configured NSS Ciphers [23/Sep/2015:08:51:04 -0600] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [23/Sep/2015:08:51:04 -0600] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [23/Sep/2015:08:51:04 -0600] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [23/Sep/2015:08:51:04 -0600] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [23/Sep/2015:08:51:04 -0600] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [23/Sep/2015:08:51:04 -0600] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [23/Sep/2015:08:51:04 -0600] - 389-Directory/1.3.3.8 B2015.040.128 starting up But sslscan returns: $ sslscan --no-failed localhost:636 ... Supported Server Cipher(s): Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 128 bits DES-CBC3-SHA Accepted TLSv1 128 bits RC4-SHA Accepted TLSv1 128 bits RC4-MD5 Accepted TLS11 256 bits AES256-SHA Accepted TLS11 128 bits AES128-SHA Accepted TLS11 128 bits DES-CBC3-SHA Accepted TLS11 128 bits RC4-SHA Accepted TLS11 128 bits RC4-MD5 Accepted TLS12 256 bits AES256-SHA256 Accepted TLS12 256 bits AES256-SHA Accepted TLS12 128 bits AES128-GCM-SHA256 Accepted TLS12 128 bits AES128-SHA256 Accepted TLS12 128 bits AES128-SHA Accepted TLS12 128 bits DES-CBC3-SHA Accepted TLS12 128 bits RC4-SHA Accepted TLS12 128 bits RC4-MD5 ... I would assume the sslscan is broken, but nmap and other scanners all confirm that RC4 is still on. -M On Wed, Sep 23, 2015 at 3:35 AM, Martin Kosek <mko...@redhat.com> wrote: > On 09/23/2015 11:00 AM, Michael Lasevich wrote: > > OK, this is most bizarre issue, > > > > I am trying to disable RC4 based TLS Cipher Suites in LDAPs(port 636) and > > for the life of me cannot get it to work > > > > I have followed many nearly identical instructions to create ldif file > and > > change "nsSSL3Ciphers" in "cn=encryption,cn=config". Seems simple enough > - > > and I get it to take, and during the startup I can see the right SSL > Cipher > > Suites listed in errors.log - but when it starts and I probe it, RC4 > > ciphers are still there. I am completely confused. > > > > I tried setting "nsSSL3Ciphers" to "default" (which does not have "RC4") > > and to old style cyphers lists(lowercase), and new style cypher > > lists(uppercase), and nothing seems to make any difference. > > > > Any ideas? > > > > -M > > Are you asking about standalone 389-DS or the one integrated in FreeIPA? As > with currently supported versions of FreeIPA, RC4 ciphers should be already > gone, AFAIK. > > In RHEL/CentOS world, it should be fixed in 6.7/7.1 or later: > > https://bugzilla.redhat.com/show_bug.cgi?id=1154687 > https://fedorahosted.org/freeipa/ticket/4653 > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] How to turn off RC4 in 389ds???
epted TLS12 256 bits AES256-SHA256 Accepted TLS12 256 bits AES256-SHA Accepted TLS12 128 bits AES128-GCM-SHA256 Accepted TLS12 128 bits AES128-SHA256 Accepted TLS12 128 bits AES128-SHA Accepted TLS12 128 bits DES-CBC3-SHA Accepted TLS12 128 bits RC4-SHA Accepted TLS12 128 bits RC4-MD5 On Wed, Sep 23, 2015 at 8:19 AM, Ludwig Krispenz <lkris...@redhat.com> wrote: > > On 09/23/2015 05:05 PM, Michael Lasevich wrote: > > Yes, I am talking about 389ds as is integrated in FreeIPA (would be silly > to post completely non-IPA questions to this list...). > I am running FreeIPA 4.1.4 on CentOS 7.1 and RC4 is enabled on port 636 no > matter what I do. > > I am running "CentOS Linux release 7.1.1503 (Core)" > > Relevant Packages: > > freeipa-server-4.1.4-1.el7.centos.x86_64 > 389-ds-base-1.3.3.8-1.el7.centos.x86_64 > nss-3.19.1-5.el7_1.x86_64 > openssl-1.0.1e-42.el7.9.x86_64 > > LDAP setting (confirmed that in error.log there is no menition of RC4 in > list of ciphers): > > nsSSL3Ciphers: > -rc4,-rc4export,-rc2,-rc2export,-des,-desede3,-rsa_rc4_128_md5,-rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,+rsa_fips_3des_sha,+fips_3des_sha,-rsa_fips_des_sha,-fips_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,-tls_rsa_export1024_with_rc4_56_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_des_cbc_sha,-rsa_des_56_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-dhe_dss_des_sha,+dhe_dss_3des_sha,-dhe_rsa_des_sha,+dhe_rsa_3des_sha,+tls_rsa_aes_128_sha,+rsa_aes_128_sha,+tls_dhe_dss_aes_128_sha,+tls_dhe_rsa_aes_128_sha,+tls_rsa_aes_256_sha,+rsa_aes_256_sha,+tls_dhe_dss_aes_256_sha,+tls_dhe_rsa_aes_256_sha,-tls_dhe_dss_1024_rc4_sha,-tls_dhe_dss_rc4_128_sha > > with ipa the config entry should contain: > > dn: cn=encryption,cn=config > allowWeakCipher: off > nsSSL3Ciphers: +all > > could you try this setting > > Slapd "error" log showing no ciphersuites supporting RC4: > > [23/Sep/2015:08:51:04 -0600] SSL Initialization - Configured SSL version > range: min: TLS1.0, max: TLS1.2 > [23/Sep/2015:08:51:04 -0600] - SSL alert: Cipher suite fortezza is not > available in NSS 3.16. Ignoring fortezza > [23/Sep/2015:08:51:04 -0600] - SSL alert: Cipher suite > fortezza_rc4_128_sha is not available in NSS 3.16. Ignoring > fortezza_rc4_128_sha > [23/Sep/2015:08:51:04 -0600] - SSL alert: Cipher suite fortezza_null is > not available in NSS 3.16. Ignoring fortezza_null > [23/Sep/2015:08:51:04 -0600] - SSL alert: Configured NSS Ciphers > [23/Sep/2015:08:51:04 -0600] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > [23/Sep/2015:08:51:04 -0600] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > [23/Sep/2015:08:51:04 -0600] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > [23/Sep/2015:08:51:04 -0600] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > [23/Sep/2015:08:51:04 -0600] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA: enabled > [23/Sep/2015:08:51:04 -0600] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA: enabled > [23/Sep/2015:08:51:04 -0600] - 389-Directory/1.3.3.8 B2015.040.128 > starting up > > But sslscan returns: > > $ sslscan --no-failed localhost:636 > ... > > Supported Server Cipher(s): > > Accepted TLSv1 256 bits AES256-SHA > Accepted TLSv1 128 bits AES128-SHA > Accepted TLSv1 128 bits DES-CBC3-SHA > Accepted TLSv1 128 bits RC4-SHA > Accepted TLSv1 128 bits RC4-MD5 > Accepted TLS11 256 bits AES256-SHA > Accepted TLS11 128 bits AES128-SHA > Accepted TLS11 128 bits DES-CBC3-SHA > Accepted TLS11 128 bits RC4-SHA > Accepted TLS11 128 bits RC4-MD5 > Accepted TLS12 256 bits AES256-SHA256 > Accepted TLS12 256 bits AES256-SHA > Accepted TLS12 128 bits AES128-GCM-SHA256 > Accepted TLS12 128 bits AES128-SHA256 > Accepted TLS12 128 bits AES128-SHA > Accepted TLS12 128 bits DES-CBC3-SHA > Accepted TLS12 128 bits RC4-SHA > Accepted TLS12 128 bits RC4-MD5 > > ... > > > I would assume the sslscan is broken, but nmap and other scanners all > confirm that RC4 is still on. > > -M > > On Wed, Sep 23, 2015 at 3:35 AM, Martin Kosek <mko...@redhat.com> wrote: > >> On 09/23/2015 11:00 AM, Michael Lasevich wrote: >> > OK, this is most bizarre issue, >> > >> > I am trying to disable RC4 based TLS Cipher Suites in LDAPs(port 636) >> and >> > for the life of me cannot get it to work >> > >> > I have followed many nearly identical instructions to create ldif file >> and >> > change "nsSSL3Ciphers" in "cn=encryption,cn=config"
[Freeipa-users] Possible bug in ipa-replica-install/pkispawn - or maybe lib mismatch
Ok, I just went through process of migrating our IPA setup from 4.1.2 running on Fedora 20 (?? may have been 21) to 4.1.4 on CentOS 7 (MKosek Copr version) and run into a nasty bug. The replica-install crashes during CA configuration with something like: ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpXX'' returned non-zero exit status 1 Skipping CA works, but I needed the CA. Upon digging into this, I found the issue appears to be in pki python, in file: /usr/lib/python2.7/site-packages/pki/system.py It looks like it makes a call to "/ca/rest/securityDomain/domainInfo" and gets an XML doc which it converts to JSON. Somehow it gets mangled before it looks at it. XML has outermost tag of "DomainInfo" - but JSON starts with "Subsystem" (one layer lower) - I am guessing JSON converted strips the "root" tag. I bypassed this by hardcoding id as "IPA" - but obviously that is sub-optimal Looking at Fedora box, it looks like the difference is in the version of PKI package that provides the lib - on Centos you get pki-base 10.1.2 (pki-base-10.1.2-7.1.el7.centos.noarch) - while on Fedore it was a 10.2 branch (and significantly different content in that file) Anyway, I saw some reports of this bug in searches and no answers - so I figured I would offer this pointer in (hopefully) the right direction. -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] How to turn off RC4 in 389ds???
OK, this is most bizarre issue, I am trying to disable RC4 based TLS Cipher Suites in LDAPs(port 636) and for the life of me cannot get it to work I have followed many nearly identical instructions to create ldif file and change "nsSSL3Ciphers" in "cn=encryption,cn=config". Seems simple enough - and I get it to take, and during the startup I can see the right SSL Cipher Suites listed in errors.log - but when it starts and I probe it, RC4 ciphers are still there. I am completely confused. I tried setting "nsSSL3Ciphers" to "default" (which does not have "RC4") and to old style cyphers lists(lowercase), and new style cypher lists(uppercase), and nothing seems to make any difference. Any ideas? -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] How to turn off RC4 in 389ds???
I actually just posted that in a previous email. The only thing I cut out were nsSSLEnabledCiphers - but here is the complete listing: # ldapsearch -x -D "cn=directory manager" -W -b "cn=encryption,cn=config" Enter LDAP Password: # extended LDIF # # LDAPv3 # base
Re: [Freeipa-users] Saltstack and ipa-install on Centos7 failing
Is SELinux on?
On Mar 13, 2015 7:46 AM, Andrew Holway andrew.hol...@gmail.com wrote:
Hallo
I have a quite odd situation. I am using saltstack to set up freeipa
servers on Centos 7 but I am getting the following error:
failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent
--logfile - -f /tmp/tmp5witgD' returned non-zero exit status 1
Saltstack outputs the command it is trying to run:
ipa-server-install -a password --realm CLOUD.DOMAIN.DE -P password -p
password -n cloud.domain.de --setup-dns --unattended --no-forwarders
However if I run this command manually on a clean machine it works fine.
It works on Centos 6.
I see this in the slapd error log:
[root@freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors
389-Directory/1.3.1.6 B2014.219.1825
freeipa-2.cloud.native-instruments.de:389
(/etc/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE)
[13/Mar/2015:10:45:59 +] - Error - Unable to create
/var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape
Portable Runtime error -5966 (Access Denied.)
[13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
with other slapd processes
[13/Mar/2015:10:45:59 +] - Error - Unable to create
/var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape
Portable Runtime error -5966 (Access Denied.)
[13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
with other slapd processes
[root@freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors | sed
s/NATIVE-INSTRUMENTS/DOMAIN/g
389-Directory/1.3.1.6 B2014.219.1825
freeipa-2.cloud.native-instruments.de:389
(/etc/dirsrv/slapd-CLOUD-DOMAIN-DE)
[13/Mar/2015:10:45:59 +] - Error - Unable to create
/var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime
error -5966 (Access Denied.)
[13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
with other slapd processes
[13/Mar/2015:10:45:59 +] - Error - Unable to create
/var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime
error -5966 (Access Denied.)
[13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
with other slapd processes
ipaserver-install.log
015-03-13T10:45:57Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-03-13T10:45:57Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2015-03-13T10:45:57Z DEBUG httpd is not configured
2015-03-13T10:45:57Z DEBUG kadmin is not configured
2015-03-13T10:45:57Z DEBUG dirsrv is not configured
2015-03-13T10:45:57Z DEBUG pki-cad is not configured
2015-03-13T10:45:57Z DEBUG pki-tomcatd is not configured
2015-03-13T10:45:57Z DEBUG install is not configured
2015-03-13T10:45:57Z DEBUG krb5kdc is not configured
2015-03-13T10:45:57Z DEBUG ntpd is not configured
2015-03-13T10:45:57Z DEBUG named is not configured
2015-03-13T10:45:57Z DEBUG ipa_memcached is not configured
2015-03-13T10:45:57Z DEBUG filestore is tracking no files
2015-03-13T10:45:57Z DEBUG Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2015-03-13T10:45:57Z DEBUG /usr/sbin/ipa-server-install was invoked with
options: {'reverse_zone': None, 'mkhomedir': False, 'create_sshfp': True,
'conf_sshd': True, 'conf_ntp': True, 'subject': None, 'no_forwarders':
True, 'ui_redirect': True, 'domain_name': 'cloud.domain.de', 'idmax': 0,
'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None,
'unattended': True, 'trust_sshfp': False, 'external_ca_file': None,
'no_host_dns': False, 'http_pkcs12': None, 'realm_name': 'CLOUD.DOMAIN.DE',
'forwarders': None, 'idstart': 154440, 'external_ca': False,
'ip_address': None, 'conf_ssh': True, 'zonemgr': None, 'root_ca_file':
None, 'setup_dns': True, 'host_name': None, 'debug': False,
'external_cert_file': None, 'uninstall': False}
2015-03-13T10:45:57Z DEBUG missing options might be asked for
interactively later
2015-03-13T10:45:57Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2015-03-13T10:45:57Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-03-13T10:45:57Z DEBUG Starting external process
2015-03-13T10:45:57Z DEBUG args=/bin/systemctl is-enabled chronyd.service
2015-03-13T10:45:57Z DEBUG Process finished, return code=0
2015-03-13T10:45:57Z DEBUG stdout=enabled
2015-03-13T10:45:57Z DEBUG stderr=
2015-03-13T10:45:57Z DEBUG Starting external process
2015-03-13T10:45:57Z DEBUG args=/usr/sbin/httpd -t -D DUMP_VHOSTS
2015-03-13T10:45:57Z DEBUG Process finished, return code=0
2015-03-13T10:45:57Z DEBUG stdout=VirtualHost configuration:
*:8443 is a NameVirtualHost
default server freeipa-2.cloud.domain.de
(/etc/httpd/conf.d/nss.conf:86)
port 8443 namevhost freeipa-2.cloud.domain.de
(/etc/httpd/conf.d/nss.conf:86)
port 8443 namevhost freeipa-2.cloud.domain.de
(/etc/httpd/conf.d/nss.conf:86)
2015-03-13T10:45:57Z DEBUG stderr=
Re: [Freeipa-users] Where and how are passwords stored?
Thank you, this is very helpful. I forgot about 'super admin', which is why I was not even seeing the values before. :-) How are the the values encrypted (or hashed?) It sounds like the password is stored in two fields(I am leaving samba out for now) - userpassword andkerberos principle key. Is userpassword a hash? Of so, what kind? KerberosPrincipleKey you mention is encrypted with Kerberos master key - is the plaintext of password encrypted or is it a hash that is encrypted? What encryption and or hashing used for that? Thank you, -M On Feb 12, 2015 5:04 AM, Simo Sorce s...@redhat.com wrote: On Thu, 2015-02-12 at 02:20 -0500, Dmitri Pal wrote: On 02/12/2015 01:25 AM, Michael Lasevich wrote: Ok, after a few awkward questions from an auditor, I am starting to face the uncomfortable truth that my understanding about how FreeIPA works is a lot fuzzier than I would like. Specifically, the question I could not answer - where are the passwords stored and how are they encrypted? My understanding is that all authentication is handled by Kerberos server, which stores its data in LDAP - but where and how is a bit of a mystery to me. Any way to dump out the password hashes? Passwords are stored in LDAP in two different attributes per entry. One with LDAP password hash and another is Kerberos password hash allowing authentication either with Kerebros or LDAP. Both follow best practices in terms of using hash algorithms. The attributes themselves are protected by the access control instructions (ACI) so only a super priviledged admin or user himself can interact with this attribute. During normal operations it is not fetched and read. The core of the DS processes it behind the closed doors so it is possible to reset but not to read. This is how LDAP works and not different from any modern directory server. Keep in mind that the Kerberos keys are additionally encrypted with a master password, so reading the attribute alone is useless. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Where and how are passwords stored?
Ok, after a few awkward questions from an auditor, I am starting to face the uncomfortable truth that my understanding about how FreeIPA works is a lot fuzzier than I would like. Specifically, the question I could not answer - where are the passwords stored and how are they encrypted? My understanding is that all authentication is handled by Kerberos server, which stores its data in LDAP - but where and how is a bit of a mystery to me. Any way to dump out the password hashes? Thanks, -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Heads up - FC20 softhsm -2.0.0b1-8 rpm from mkosek/freeipa copr appears to be broken
To save a day of torture to those of you still on FC20 and using mkosek-freeipa copr repo - it appears that the package ( http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-20-x86_64/softhsm-2.0.0b1-8.fc20/softhsm-2.0.0b1-8.fc20.x86_64.rpm) is somehow broken. Once installed, you get Error: Could not load the library. no matter what you do with softhsm2-utll. You will also not going to be able to start/restart the ipa service because DNS is not functional. I have rebuilt the rpm from the source rpm and things seem to be working. Hope this helps someone to not have a day of hair pulling. You have been warned :-) -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA4 OTP vs PAM
Reviving this as I am still stuck with CentOS 6. CentOS 6.6 now has sssd 1.11 - yet I still cannot get the OTP to work under PAM: I created a test user and added an otp. User works fine without the OTP, however I keep getting this when trying to test with OTP via pamtester: pamtester: pam_sss(login:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=michael pamtester: pam_sss(login:auth): received for user michael: 17 (Failure setting user credentials) Is there a way to get more information as to what is going on? Is my expectation that I would provide otp in a form of password123456 correct (assuming my password is password and otp token is 123456)? On Fri, Aug 15, 2014 at 2:29 AM, Michael Lasevich mlasev...@lasevich.net wrote: Thanks, glad I asked before wasting time. On Fri, Aug 15, 2014 at 1:07 AM, Jakub Hrozek jhro...@redhat.com wrote: On Thu, Aug 14, 2014 at 01:19:58PM -0700, Michael Lasevich wrote: I did not dive into this yet, but before I waste too much time I wanted to ask if centos 6.5 default ipa client expected to work with 2FA or not. No it's not, sorry. The 6.5 client is SSSD 1.9.x and there's a couple of fixes that landed during the 1.11 development such as: https://fedorahosted.org/sssd/ticket/2186 or: https://fedorahosted.org/sssd/ticket/2271 plus some other commits I see in git log which don't reference any ticket. I'd suggest to test using a centos 7.0 client. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA4 OTP vs PAM
] 1416693343.366425: Armor ccache sesion key: aes256-cts/9082 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366476: Creating authenticator for host/ipaclient.my.domain@my.domain.com - krbtgt/ my.domain@my.domain.com, seqnum 0, subkey aes256-cts/F5B0, session key aes256-cts/9082 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366562: FAST armor key: aes256-cts/0D88 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366605: Encoding request body and padata into FAST request (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366675: Sending request (1089 bytes) to MY.DOMAIN.COM (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366752: Sending initial UDP request to dgram 1.1.1.2:88 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370122: Received answer from dgram 1.1.1.2:88 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370193: Response was from master KDC (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370232: Received error from KDC: -1765328359/Additional pre-authentication required (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370262: Decoding FAST response (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370333: Processing preauth types: 136, 141, 133, 137 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370364: Received cookie: MIT (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370404: Produced preauth for next request: 133 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [get_and_save_tgt] (0x0020): 981: [-1765328174][Generic preauthentication failure] (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [map_krb5_error] (0x0020): 1043: [-1765328174][Generic preauthentication failure] = On Sat, Nov 22, 2014 at 1:14 PM, Michael Lasevich mlasev...@lasevich.net wrote: Reviving this as I am still stuck with CentOS 6. CentOS 6.6 now has sssd 1.11 - yet I still cannot get the OTP to work under PAM: I created a test user and added an otp. User works fine without the OTP, however I keep getting this when trying to test with OTP via pamtester: pamtester: pam_sss(login:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=michael pamtester: pam_sss(login:auth): received for user michael: 17 (Failure setting user credentials) Is there a way to get more information as to what is going on? Is my expectation that I would provide otp in a form of password123456 correct (assuming my password is password and otp token is 123456)? On Fri, Aug 15, 2014 at 2:29 AM, Michael Lasevich mlasev...@lasevich.net wrote: Thanks, glad I asked before wasting time. On Fri, Aug 15, 2014 at 1:07 AM, Jakub Hrozek jhro...@redhat.com wrote: On Thu, Aug 14, 2014 at 01:19:58PM -0700, Michael Lasevich wrote: I did not dive into this yet, but before I waste too much time I wanted to ask if centos 6.5 default ipa client expected to work with 2FA or not. No it's not, sorry. The 6.5 client is SSSD 1.9.x and there's a couple of fixes that landed during the 1.11 development such as: https://fedorahosted.org/sssd/ticket/2186 or: https://fedorahosted.org/sssd/ticket/2271 plus some other commits I see in git log which don't reference any ticket. I'd suggest to test using a centos 7.0 client. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6
Sending you logs directly. Thanks. -M On 11/11/14, 5:33 AM, Jakub Hrozek wrote: On Mon, Nov 10, 2014 at 09:29:04AM -0800, Michael Lasevich wrote: I can certainly try, it would need to be compatible with CentOS 6.6 though. -M Thank you very much, can you try these packages? Please note they wouldn't fix your problem, but will hopefully shed some more light on what's going on: https://jhrozek.fedorapeople.org/sssd-test-builds/krb5-ccache-debugging/ So according to the logs, the create_ccache() function failed. Unfortunately, we don't do very good job at logging the failures there.. Michael, are you able to run a custom package with extra debugging? It would help us pinpoint which line actually is failing. Thanks a lot for providing the logs! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6
I can certainly try, it would need to be compatible with CentOS 6.6 though. -M So according to the logs, the create_ccache() function failed. Unfortunately, we don't do very good job at logging the failures there.. Michael, are you able to run a custom package with extra debugging? It would help us pinpoint which line actually is failing. Thanks a lot for providing the logs! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6
I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11 (centos 6.5 to 6.6) I seem to be able to log in via ssh, but when I use http pam service, I get inconsistent behavior - seems like sometimes it works and others it errors out (success and failure can happen within a second) In the logs I see things like: [sssd[krb5_child[15410]]]: Internal credentials cache error and authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= user=username received for user username: 4 (System error) Nothing in the audit.log that I can see I am guessing this is an sssd issue but I am hoping someone here knows how to deal with it. IN case it matters - here is the pam config: authrequired pam_env.so authsufficientpam_sss.so authrequired pam_deny.so account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session optional pam_sss.so -M On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek jhro...@redhat.com wrote: On Wed, Nov 05, 2014 at 02:30:55AM +, David Taylor wrote: Thanks for the reply. The PAM file is pretty stock for a centos build #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Best regards David Taylor OK, so pam_sss is there ... And yet you see no mention of pam_sss.so in /var/log/secure ? Is this the file that was included from the service-specific PAM configuration? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6
For what its worth, my issue was resolved when I rebooted the server. Restarting sssd and/or clearing it's cache did not do it, but a full reboot seems to have done it. Something much have been cached or some temp file I missed. Will need to look into it further as I have a number of servers yet to be upgraded and having to reboot linux servers to do an upgrade seem sacrilegious... -M On Thu, Nov 6, 2014 at 9:26 PM, David Taylor david.tay...@speedcast.com wrote: As an add on, I’ve upgraded our Xen template to 6.6 and run up a new VM using that and it attaches to the IPA environment perfectly well, so I’m guessing it is an issue with the upgrade scripts. Best regards *David Taylor* *From:* Michael Lasevich [mailto:mlasev...@gmail.com] *Sent:* Friday, 7 November 2014 4:00 PM *To:* Jakub Hrozek *Cc:* David Taylor; freeipa-users@redhat.com *Subject:* Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11 (centos 6.5 to 6.6) I seem to be able to log in via ssh, but when I use http pam service, I get inconsistent behavior - seems like sometimes it works and others it errors out (success and failure can happen within a second) In the logs I see things like: [sssd[krb5_child[15410]]]: Internal credentials cache error and authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= user=username received for user username: 4 (System error) Nothing in the audit.log that I can see I am guessing this is an sssd issue but I am hoping someone here knows how to deal with it. IN case it matters - here is the pam config: authrequired pam_env.so authsufficientpam_sss.so authrequired pam_deny.so account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session optional pam_sss.so -M On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek jhro...@redhat.com wrote: On Wed, Nov 05, 2014 at 02:30:55AM +, David Taylor wrote: Thanks for the reply. The PAM file is pretty stock for a centos build #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Best regards David Taylor OK, so pam_sss is there ... And yet you see no mention of pam_sss.so in /var/log/secure ? Is this the file that was included from the service-specific PAM configuration? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Errors upgrading 4.0.1 to 4.1
Thank you!!! That was exactly it. * Removed the nsEncryptionConfig entry from 99user.ldif * Re-run the ipa-ldap-update --upgrade * Then ipa-dns-install and things are looking much better - both servers are now back up and running. What is the lesson here (besides have good backups)? Should we be turning off ALL servers before upgrading to prevent replication? I did notice that the 99user entry was made it to BOTH servers, which makes me think that replication is not exactly the culprit. -M On 10/31/14, 1:30 AM, Ludwig Krispenz wrote: On 10/30/2014 07:36 PM, Martin Basti wrote: On 30/10/14 19:18, Michael Lasevich wrote: Makes sense. What is the solution here? I have the latest 389-ds installed but still getting allowWeakCipher error - how to I get around that? -M Sorry I don't know, I CCied Ludwig, he is DS guru. I already asked to verify the schema files: can you check your schema files for the definition of the nsEncryptionConfig objectclass, it should be only in 01core389.ldif and contain allowWeakCipher, but it could have been added also to 99user.ldif during replication when schema changes have been consolidated and what is the latest ds version you are using: rpm -q 389-ds-base Martin^2 On 10/30/14, 11:12 AM, Martin Basti wrote: On 24/10/14 05:17, Michael Lasevich wrote: While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one of the two boxes: Upgrade failed with attribute allowWeakCipher not allowed IPA upgrade failed. Unexpected error DuplicateEntry: This entry already exists Named errors are caused by cascade effect, if ldap schema and entry updates failed, there is misconfigured DS plugin which is responsible to keep DNSSEC keys DN unique, what causes duplication errors. DuplicateEntry exception is fatal, so dnskeysyncd installation will not continue, what causes there are not appropriate permissions for token database, and named-pkcs11 can't read tokens. It seems the ipa no longer starts up after this. The replica server seems to have had same error,but it runs just fine. From digging around, it appears that there are a number of GSS errors in dirsrv and bind fails with something like: named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token e919db16-6329-406c-6ae4-120ad68508c4 named-pkcs11[2212]: sha1.c:92: fatal error: named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), 0) == 0) failed Any help would be appreciated -M -- Martin Basti -- Martin Basti -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] IPA Backup in AWS - best practices?
What is the current best practice for backing up IPA servers? Especially in AWS? Given AWS strengths and weaknesses, I would love to be able to move all of IPA data/state onto a separate drive and just snapshot it on regular basis - but it seems that IPA data is all over the place, so it is hard to separate it from the rest of the OS. Snapshotting entire root drive is another option, but restoring from that is a bit of a pain, so it may not be optimal. There is always also the plain old tar it all up approach. What do people use? What works, what does not? Thanks, -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] F20 Problem upgrading to 4.1
*sigh* Feel like I am going around in circles ipa-ldap-updater --upgrade failed with: Upgrade failed with attribute allowWeakCipher not allowed I am running 1.3.3 from mkosek-freeipa copr: 389-ds-base-libs-1.3.3.5-1.fc20.x86_64 389-ds-base-1.3.3.5-1.fc20.x86_64 yum info 389-ds-base Loaded plugins: copr Installed Packages Name: 389-ds-base Arch: x86_64 Version : 1.3.3.5 Release : 1.fc20 Size: 5.2 M Repo: installed From repo : mkosek-freeipa Summary : 389 Directory Server (base) URL : http://port389.org/ License : GPLv2 with exceptions Description : 389 Directory Server is an LDAPv3 compliant server. The base package includes : the LDAP server and command line utilities for server administration. -M On 10/30/14, 1:44 AM, Martin Basti wrote: On 30/10/14 06:09, Michael Lasevich wrote: Maybe I should not be doing this late at night, but I cannot find cn=IPK11 Unique IDs,cn=IPA UUID,cn=plugins,cn=config anywhere. -M IMO something bad happens during the ipa upgrade, can you remove ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com entry, and run ipa-ldap-updater --upgrade, then reinstall DNS (rerun ipa-dns-install) Let me know if it works. On 10/29/14, 3:03 AM, Martin Basti wrote: On 28/10/14 20:54, Michael Lasevich wrote: I have a pair of servers that were both installed on clean Fedora20 4.0.1 from pviktori copr repo and then upgraded from mkosek to 4.1 During update, secondary was done first and worked but primary run into trouble as described Looking under cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com I get one entry with dn: ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com Not sure what of that you need there, but for ipk11Label it has: dnssec-replica:infra-dc-02.my.domain.com. (which is the replica that IS working) Thanks, -M On 10/28/14, 3:21 AM, Martin Basti wrote: On 28/10/14 06:14, Michael Lasevich wrote: Running into same thing, but running ipa-dnsinstall does not complete: = Configuring DNS (named) [1/8]: generating rndc key file WARNING: Your system is running out of entropy, you may experience long delays [2/8]: setting up our own record [3/8]: adding NS record to the zones [4/8]: setting up CA record [5/8]: setting up kerberos principal [6/8]: setting up named.conf [7/8]: configuring named to start on boot [8/8]: changing resolv.conf to point to ourselves Done configuring DNS (named). Configuring DNS key synchronization service (ipa-dnskeysyncd) [1/6]: checking status [2/6]: setting up kerberos principal [3/6]: setting up SoftHSM [4/6]: adding DNSSEC containers [5/6]: creating replica keys [error] DuplicateEntry: This entry already exists Unexpected error - see /var/log/ipaserver-install.log for details: DuplicateEntry: This entry already exists = Looking into the /var/log/ipaserver-install.log gets: = 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com 2014-10-28T05:01:24Z DEBUG flushing ldap://infra-dc-01.my.domain.com:389 from SchemaCache 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache url=ldap://infra-dc-01.my.domain.com:389 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x47d0d88 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 340, in __setup_replica_keys ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1169, in error_handler raise errors.DuplicateEntry() DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 646, in run_script return_value = main_function() File /sbin/ipa-dns-install, line 218, in main dnskeysyncd.create_instance(api.env.host, api.env.realm) File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 128, in create_instance self.start_creation() File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib
Re: [Freeipa-users] Errors upgrading 4.0.1 to 4.1
Makes sense. What is the solution here? I have the latest 389-ds installed but still getting allowWeakCipher error - how to I get around that? -M On 10/30/14, 11:12 AM, Martin Basti wrote: On 24/10/14 05:17, Michael Lasevich wrote: While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one of the two boxes: Upgrade failed with attribute allowWeakCipher not allowed IPA upgrade failed. Unexpected error DuplicateEntry: This entry already exists Named errors are caused by cascade effect, if ldap schema and entry updates failed, there is misconfigured DS plugin which is responsible to keep DNSSEC keys DN unique, what causes duplication errors. DuplicateEntry exception is fatal, so dnskeysyncd installation will not continue, what causes there are not appropriate permissions for token database, and named-pkcs11 can't read tokens. It seems the ipa no longer starts up after this. The replica server seems to have had same error,but it runs just fine. From digging around, it appears that there are a number of GSS errors in dirsrv and bind fails with something like: named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token e919db16-6329-406c-6ae4-120ad68508c4 named-pkcs11[2212]: sha1.c:92: fatal error: named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), 0) == 0) failed Any help would be appreciated -M -- Martin Basti -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] F20 Problem upgrading to 4.1
Maybe I should not be doing this late at night, but I cannot find cn=IPK11 Unique IDs,cn=IPA UUID,cn=plugins,cn=config anywhere. -M On 10/29/14, 3:03 AM, Martin Basti wrote: On 28/10/14 20:54, Michael Lasevich wrote: I have a pair of servers that were both installed on clean Fedora20 4.0.1 from pviktori copr repo and then upgraded from mkosek to 4.1 During update, secondary was done first and worked but primary run into trouble as described Looking under cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com I get one entry with dn: ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com Not sure what of that you need there, but for ipk11Label it has: dnssec-replica:infra-dc-02.my.domain.com. (which is the replica that IS working) Thanks, -M On 10/28/14, 3:21 AM, Martin Basti wrote: On 28/10/14 06:14, Michael Lasevich wrote: Running into same thing, but running ipa-dnsinstall does not complete: = Configuring DNS (named) [1/8]: generating rndc key file WARNING: Your system is running out of entropy, you may experience long delays [2/8]: setting up our own record [3/8]: adding NS record to the zones [4/8]: setting up CA record [5/8]: setting up kerberos principal [6/8]: setting up named.conf [7/8]: configuring named to start on boot [8/8]: changing resolv.conf to point to ourselves Done configuring DNS (named). Configuring DNS key synchronization service (ipa-dnskeysyncd) [1/6]: checking status [2/6]: setting up kerberos principal [3/6]: setting up SoftHSM [4/6]: adding DNSSEC containers [5/6]: creating replica keys [error] DuplicateEntry: This entry already exists Unexpected error - see /var/log/ipaserver-install.log for details: DuplicateEntry: This entry already exists = Looking into the /var/log/ipaserver-install.log gets: = 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com 2014-10-28T05:01:24Z DEBUG flushing ldap://infra-dc-01.my.domain.com:389 from SchemaCache 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache url=ldap://infra-dc-01.my.domain.com:389 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x47d0d88 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 340, in __setup_replica_keys ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1169, in error_handler raise errors.DuplicateEntry() DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 646, in run_script return_value = main_function() File /sbin/ipa-dns-install, line 218, in main dnskeysyncd.create_instance(api.env.host, api.env.realm) File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 128, in create_instance self.start_creation() File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 340, in __setup_replica_keys ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1169, in error_handler raise errors.DuplicateEntry() 2014-10-28T05:01:24Z DEBUG The ipa-dns-install command failed, exception: DuplicateEntry: This entry already exists Hello Michael, can you send me which entries do you have in cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com, it looks like directory server doesn't generate uniqueID for keys. Do you have upgraded IPA or fresh installed? Martin^2 Can you send me content of cn=IPK11 Unique IDs,cn=IPA UUID,cn=plugins,cn=config entry? (If exists) It looks like DS doesn't generate unique IDs Martin^2 -- Manage your subscription for the Freeipa-users mailing list: https
Re: [Freeipa-users] F20 Problem upgrading to 4.1
I have a pair of servers that were both installed on clean Fedora20 4.0.1 from pviktori copr repo and then upgraded from mkosek to 4.1 During update, secondary was done first and worked but primary run into trouble as described Looking under cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com I get one entry with dn: ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com Not sure what of that you need there, but for ipk11Label it has: dnssec-replica:infra-dc-02.my.domain.com. (which is the replica that IS working) Thanks, -M On 10/28/14, 3:21 AM, Martin Basti wrote: On 28/10/14 06:14, Michael Lasevich wrote: Running into same thing, but running ipa-dnsinstall does not complete: = Configuring DNS (named) [1/8]: generating rndc key file WARNING: Your system is running out of entropy, you may experience long delays [2/8]: setting up our own record [3/8]: adding NS record to the zones [4/8]: setting up CA record [5/8]: setting up kerberos principal [6/8]: setting up named.conf [7/8]: configuring named to start on boot [8/8]: changing resolv.conf to point to ourselves Done configuring DNS (named). Configuring DNS key synchronization service (ipa-dnskeysyncd) [1/6]: checking status [2/6]: setting up kerberos principal [3/6]: setting up SoftHSM [4/6]: adding DNSSEC containers [5/6]: creating replica keys [error] DuplicateEntry: This entry already exists Unexpected error - see /var/log/ipaserver-install.log for details: DuplicateEntry: This entry already exists = Looking into the /var/log/ipaserver-install.log gets: = 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com 2014-10-28T05:01:24Z DEBUG flushing ldap://infra-dc-01.my.domain.com:389 from SchemaCache 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache url=ldap://infra-dc-01.my.domain.com:389 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x47d0d88 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 340, in __setup_replica_keys ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1169, in error_handler raise errors.DuplicateEntry() DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 646, in run_script return_value = main_function() File /sbin/ipa-dns-install, line 218, in main dnskeysyncd.create_instance(api.env.host, api.env.realm) File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 128, in create_instance self.start_creation() File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 340, in __setup_replica_keys ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1169, in error_handler raise errors.DuplicateEntry() 2014-10-28T05:01:24Z DEBUG The ipa-dns-install command failed, exception: DuplicateEntry: This entry already exists Hello Michael, can you send me which entries do you have in cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com, it looks like directory server doesn't generate uniqueID for keys. Do you have upgraded IPA or fresh installed? Martin^2 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] F20 Problem upgrading to 4.1
Running into same thing, but running ipa-dnsinstall does not complete: = Configuring DNS (named) [1/8]: generating rndc key file WARNING: Your system is running out of entropy, you may experience long delays [2/8]: setting up our own record [3/8]: adding NS record to the zones [4/8]: setting up CA record [5/8]: setting up kerberos principal [6/8]: setting up named.conf [7/8]: configuring named to start on boot [8/8]: changing resolv.conf to point to ourselves Done configuring DNS (named). Configuring DNS key synchronization service (ipa-dnskeysyncd) [1/6]: checking status [2/6]: setting up kerberos principal [3/6]: setting up SoftHSM [4/6]: adding DNSSEC containers [5/6]: creating replica keys [error] DuplicateEntry: This entry already exists Unexpected error - see /var/log/ipaserver-install.log for details: DuplicateEntry: This entry already exists = Looking into the /var/log/ipaserver-install.log gets: = 2014-10-28T05:01:24Z DEBUG Storing replica public key to LDAP, ipk11UniqueId=autogenerate,cn=keys,cn=sec,cn=dns,dc=my,dc=domain,dc=com 2014-10-28T05:01:24Z DEBUG flushing ldap://infra-dc-01.my.domain.com:389 from SchemaCache 2014-10-28T05:01:24Z DEBUG retrieving schema for SchemaCache url=ldap://infra-dc-01.my.domain.com:389 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x47d0d88 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 340, in __setup_replica_keys ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1169, in error_handler raise errors.DuplicateEntry() DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG [error] DuplicateEntry: This entry already exists 2014-10-28T05:01:24Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 646, in run_script return_value = main_function() File /sbin/ipa-dns-install, line 218, in main dnskeysyncd.create_instance(api.env.host, api.env.realm) File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 128, in create_instance self.start_creation() File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 340, in __setup_replica_keys ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1169, in error_handler raise errors.DuplicateEntry() 2014-10-28T05:01:24Z DEBUG The ipa-dns-install command failed, exception: DuplicateEntry: This entry already exists -M On 10/27/14, 12:52 PM, Martin Basti wrote: On 27/10/14 20:50, John Obaterspok wrote: Hello Martin, It works perfectly again! note, I noticed in /var/log/ipaserver-install.log that ipa-dns-installed failed due to 389 wasn't started (failed to connect). Once it was started manually the ipa-dns-installed worked fine. Thanks a lot Martin, -- john You are welcome :-) 2014-10-27 20:40 GMT+01:00 Martin Basti mba...@redhat.com mailto:mba...@redhat.com: On 27/10/14 20:34, John Obaterspok wrote: hmm... Could not connect to the Directory Server So I started it with start-dirsrv since systemctl start ipa failed. Then it was a breeze, ipa-dns-install worked fine. # systemctl --failed 0 loaded units listed. I'm lost, does IPA work or not? are all services running? (ipactl status) are tokens created in /var/lib/ipa/dnssec/tokens can you dig records from IPA DNS? Martin^2 I haven't verified that it works, but I feel confident :) -- john 2014-10-27 20:09 GMT+01:00 Martin Basti mba...@redhat.com mailto:mba...@redhat.com: On 27/10/14 19:57, John Obaterspok wrote: Hello Martin, Still no go. I installed the softhsm-devel package (that only contains header files), removed the token directory, reinstalled the bind bind-pkcs11, did ipa-dns-install that completed ok (I guess):
Re: [Freeipa-users] Inconsistent group memberships in sssd
It was a clean install of 4.0.1(not 4.0.3, I was wrong). I have upgraded to 4.1 and have not yet seen the problem recur - though I have not tested it much yet. On Oct 24, 2014 12:53 AM, Jakub Hrozek jhro...@redhat.com wrote: On Thu, Oct 23, 2014 at 05:19:38PM -0700, Michael Lasevich wrote: Small update, it appears that once I run getent group groupname - my user shows up in the group groupname. Odd. (and yes, I have ran sss_cache -UG many a time) -M One particular change in IPA 4.x that might be giving old clients headache is the new permission system. Only clean installs or replicas of 6.6 (or newer) servers are guaranteed to work with old clients. How was your IPA 4.0.3 server installed? What is the 389-ds-base version you're running? Any chance you can try a newer SSSD on your CentOS6 client? I have a COPR repo with the latest 1.11 branch here: http://copr-fe.cloud.fedoraproject.org/coprs/jhrozek/SSSD-1.11-RHEL6/ -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Inconsistent group memberships in sssd
FreeIPA 4.0.3 server with SSSD 1.9.2 on CentOS6 Seems that group membership is completely inconsistent Running id in shell as my user on: * ipa server - I am a member of 2 groups * Server that just came up and joined - 1 group * Server that has been up for some time - 5 groups Via UI: Member of 7 groups directly and 1 indirect Gets weirder - I added a line to sudoers file (not ipa sudo support, can't get that to work) allowing certain group I am a member of. If I run sudo as the user - i get rejected as not being in sudoers, however if I run check as root: sudo -l -U username I see that I should be allowed. More wierdness, If I do getent group groupname - it shows me as a member - but I do not recall having this much trouble with same sssd and 3.0 server :-( Any thoughts? -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Inconsistent group memberships in sssd
Small update, it appears that once I run getent group groupname - my user shows up in the group groupname. Odd. (and yes, I have ran sss_cache -UG many a time) -M On Thu, Oct 23, 2014 at 5:15 PM, Michael Lasevich mlasev...@gmail.com wrote: FreeIPA 4.0.3 server with SSSD 1.9.2 on CentOS6 Seems that group membership is completely inconsistent Running id in shell as my user on: * ipa server - I am a member of 2 groups * Server that just came up and joined - 1 group * Server that has been up for some time - 5 groups Via UI: Member of 7 groups directly and 1 indirect Gets weirder - I added a line to sudoers file (not ipa sudo support, can't get that to work) allowing certain group I am a member of. If I run sudo as the user - i get rejected as not being in sudoers, however if I run check as root: sudo -l -U username I see that I should be allowed. More wierdness, If I do getent group groupname - it shows me as a member - but I do not recall having this much trouble with same sssd and 3.0 server :-( Any thoughts? -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Errors upgrading 4.0.1 to 4.1
While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one of the two boxes: Upgrade failed with attribute allowWeakCipher not allowed IPA upgrade failed. Unexpected error DuplicateEntry: This entry already exists It seems the ipa no longer starts up after this. The replica server seems to have had same error,but it runs just fine. From digging around, it appears that there are a number of GSS errors in dirsrv and bind fails with something like: named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token e919db16-6329-406c-6ae4-120ad68508c4 named-pkcs11[2212]: sha1.c:92: fatal error: named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), 0) == 0) failed Any help would be appreciated -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Use of SAN's with automatic certificates in FreeIPA 4
Martin, this was extremely helpful. I got it to work manually, now all I
need to do is automate the process :-)
The only thing missing from this is that I needed to do ipa host-add
san.host.example.test before your other ipa service-add commands . You
mentioned it, but not shown the command, so for those who will want to
follow the script, it is an essential part of the process.
Thank you so much,
-M
On Mon, Sep 15, 2014 at 7:53 AM, Martin Kosek mko...@redhat.com wrote:
On 09/12/2014 09:19 PM, Dmitri Pal wrote:
On 09/12/2014 02:43 PM, Michael Lasevich wrote:
That is awesome, but I am clearly missing some insight as to how this is
supposed to work. Can you point me to some more specific info on how to
accomplish this.
I tried using the ipa-getcert request with multiple -D's from the
client, but
got :
** Insufficient access: You need to be a member of the serviceadmin
role to
add services
Unless I am missing something, I should probably not add each host to
serviceadmins for security reasons.
4.0 has a new permissions system this might yet to be another use case
that we
might have overlooked.
Not, not really - this part works well with 4.0.
I will leave to developers to review this situation on Monday morning.
So I then I tried generating a csr via openssl with SANs on the client
and
then adding it using ipa cert-request file.csr --prinicple
host/${client_hostname}@DOMAIN from ipa server as admin (just to be
sure)
and got this error (where ALIAS is the first SAN):
** ipa: ERROR: The service principal for subject alt name ALIAS in
certificate request does not exist
It sounds like I need to create service principal for each SAN, but I
can't
seem to figure out how to do it (only allows me to create service
prinicpals
for existing hosts)
You need to create an (unused) host for the SAN service first. After that
you
can create the service. Dummy service/host entries with appropriate
managedby
attribute are used to authorize which host/service.
I did a quick test with latest FreeIPA 4.0.3 and it worked for me:
# ipa-getcert request -d /etc/httpd/nssdb -n Server-Cert -K
test/`hostname` -N
CN=`hostname`,O=EXAMPLE.COM -D san.host.example.test -g 2048
New signing request 20140915143901 added.
# ipa-getcert list -i 20140915143901
Number of certificates and requests being tracked: 8.
Request ID '20140915143901':
status: CA_REJECTED
ca-error: Server at https://ipa.mkosek-fedora20.test/ipa/xml
denied our
request, giving up: 2100 (RPC failed at server. Insufficient access: You
need
to be a member of the serviceadmin role to add services).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS
Certificate DB'
certificate:
type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
This is expected, now the authorization needs to be added:
# ipa service-add test/`hostname`
# ipa service-add test/san.host.example.test --force
# ipa service-add-host test/san.host.example.test --host `hostname`
Principal: test/san.host.example.t...@mkosek-fedora20.test
Managed by: san.host.example.test, ipa.mkosek-fedora20.test
-
Number of members added 1
-
# ipa-getcert resubmit -i 20140915143901
Resubmitting 20140915143901 to IPA.
# ipa-getcert list -i 20140915143901
Number of certificates and requests being tracked: 8.
Request ID '20140915143901':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS
Certificate DB'
certificate:
type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=MKOSEK-FEDORA20.TEST
subject: CN=ipa.mkosek-fedora20.test,O=MKOSEK-FEDORA20.TEST
expires: 2016-09-15 14:48:01 UTC
dns: san.host.example.test
principal name: test/ipa.mkosek-fedora20.t...@mkosek-fedora20.test
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
# certutil -L -d /etc/httpd/nssdb -n Server-Cert
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 11 (0xb)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: CN=Certificate Authority,O=MKOSEK-FEDORA20.TEST
Validity:
Not Before: Mon Sep 15 14:48:01 2014
Not After : Thu Sep 15 14:48:01 2016
Subject: CN=ipa.mkosek-fedora20.test,O=MKOSEK-FEDORA20.TEST
Re: [Freeipa-users] Use of SAN's with automatic certificates in FreeIPA 4
That is awesome, but I am clearly missing some insight as to how this is
supposed to work. Can you point me to some more specific info on how to
accomplish this.
I tried using the ipa-getcert request with multiple -D's from the client,
but got :
** Insufficient access: You need to be a member of the serviceadmin role to
add services
Unless I am missing something, I should probably not add each host to
serviceadmins for security reasons.
So I then I tried generating a csr via openssl with SANs on the client and
then adding it using ipa cert-request file.csr --prinicple
host/${client_hostname}@DOMAIN from ipa server as admin (just to be sure)
and got this error (where ALIAS is the first SAN):
** ipa: ERROR: The service principal for subject alt name ALIAS in
certificate request does not exist
It sounds like I need to create service principal for each SAN, but I can't
seem to figure out how to do it (only allows me to create service
prinicpals for existing hosts)
Any help or pointers would be greatly appreciated
-M
On Fri, Sep 12, 2014 at 4:12 AM, Dmitri Pal d...@redhat.com wrote:
On 09/11/2014 09:25 PM, Michael Lasevich wrote:
If I remember correctly, you could not use SAN (Subject Alternate
Names) for certificates in FreeIPA 3.0 - is this still the case with 4?
https://fedorahosted.org/freeipa/ticket/3977 4.0 is able.
I have hosts that automatically receive two hostnames, a long proper name
(like service-i-12345678) and a simpler cname based on an index for ease
of access (like service-1) - however since OS hostname is the proper
one, certs would typically be issued to that name. I want my users to be
able to hit it via the simplex index names. Is that currently possible
(esp given that the cnames are actualy in a different DNS domain)?
Thanks,
-M
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
[Freeipa-users] Use of SAN's with automatic certificates in FreeIPA 4
If I remember correctly, you could not use SAN (Subject Alternate Names) for certificates in FreeIPA 3.0 - is this still the case with 4? I have hosts that automatically receive two hostnames, a long proper name (like service-i-12345678) and a simpler cname based on an index for ease of access (like service-1) - however since OS hostname is the proper one, certs would typically be issued to that name. I want my users to be able to hit it via the simplex index names. Is that currently possible (esp given that the cnames are actualy in a different DNS domain)? Thanks, -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Minimal permissions for joiner account?
I wanted to use the python ipalib directly, but like you mentioned, I found very little documentation and what I found indicated I was going to just pass cli arguments to it, it seemed to be not much better than calling the wrapper directly :-( I will clean up my salt reactor of things specific to my install (mostly just validating host against AWS and pulling AWS info to be added to the host description fields) and try to add it to the salt-forumulas - then we can link to it from the how-tos, etc. If someone is interested sooner, I can post it here for time being. As far as Host-Enrollment vs Host-Administrators privileges - it may be that I am mixing up 2 ways to enroll hosts. My original attempt was to try to have an enroller account that would add client directly from the client - but I have relented and switched to a more proper method of adding a host entrue with a generated OTP for the client followed by joining of that client from the client itself with the OTP password. This works, but when I try to add host entry with OTP password using account with only Host Enrollment privilege I get: ipa: ERROR: Insufficient access: Insufficient 'add' privilege to the 'userPassword' attribute I really would like to have minimal privileges for my adder account, but at least this account is only available on a much more restricted server (salt-master) where only limited admins have access to it. For now I am granting it the Host Administrators privilege, as it is what works. -M On Fri, Aug 15, 2014 at 9:26 AM, Petr Viktorin pvikt...@redhat.com wrote: On 08/15/2014 06:02 PM, James wrote: On Fri, Aug 15, 2014 at 5:25 AM, Michael Lasevich mlasev...@lasevich.net wrote: Sorry, I did not intend to belittle your efforts - just misread the code Didn't take it that way, no worries :) (saw you pass in $admin and $password and made wrong assumption that $admin was admin username) as well as trying to avoid puppet as I find Salt much quicker and much simpler (and already established in my setup) I sat down tonight and threw together a quick salt reactor that does same thing as your module - creates the host account in IPA with a generated OTP password and joins the host to the domain using that generated OTP (and while at it, validates the host against AWS and populates the metadata into IPA) Ended up having to join the salt master to the domain, which I was avoiding doing for security reasons, but I can just disable IPA logins in PAM and call it a day. The nice bit is that it is using the host's keytab for authentication, so I do not need any extra credentials sitting around. Seems to be working just fine. :-). I ended up granting the salt-master host the Host Administrators privilege. It seems that Host Enrollment privilege is not sufficient to enroll hosts - go figure. Great! The only thing that bugs me is that I am calling IPA python code from my salt reactor python code via subprocess - there has got to be a better, more direct way - but I found documentation too confusing to follow at 1 am - will be a project for another day. There is the python ipa API, not sure how stable or official it is, but if you look in my code I use it occasionally. The RPC API is not official (i.e. documented), but since IPA needs to keep backwards compatibility with its own client, it's very stable. Just be sure to send the API version with each call. (The server will send a warning if you don't.) -- Petr³ -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Minimal permissions for joiner account?
Sorry, I did not intend to belittle your efforts - just misread the code (saw you pass in $admin and $password and made wrong assumption that $admin was admin username) as well as trying to avoid puppet as I find Salt much quicker and much simpler (and already established in my setup) I sat down tonight and threw together a quick salt reactor that does same thing as your module - creates the host account in IPA with a generated OTP password and joins the host to the domain using that generated OTP (and while at it, validates the host against AWS and populates the metadata into IPA) Ended up having to join the salt master to the domain, which I was avoiding doing for security reasons, but I can just disable IPA logins in PAM and call it a day. The nice bit is that it is using the host's keytab for authentication, so I do not need any extra credentials sitting around. Seems to be working just fine. :-). I ended up granting the salt-master host the Host Administrators privilege. It seems that Host Enrollment privilege is not sufficient to enroll hosts - go figure. The only thing that bugs me is that I am calling IPA python code from my salt reactor python code via subprocess - there has got to be a better, more direct way - but I found documentation too confusing to follow at 1 am - will be a project for another day. Thanks for your help. -M On Thu, Aug 14, 2014 at 6:50 PM, James purplei...@gmail.com wrote: On Thu, Aug 14, 2014 at 8:29 PM, Michael Lasevich mlasev...@lasevich.net wrote: I appreciate it. Maybe I did not read it close enough, but it seemed to send the admin password to every client, which is what I am trying to avoid. Oh no!! Definitely not :) I went to great pains to specifically avoid this actually. If you're interested in how the DM and admin passwords are managed, read: https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ If you're interested in how the clients auth, they do so via getkeytab, and in order for that to work, puppet passes a temporary one-time password to the client, uses it, and verifies that _that_ client auth-ed. If the password isn't used by that client, then a new OTP is generated, and the original is discarded (as it was probably used by the wrong client, or maliciously in that rare scenario). All of this to say, that this was quite complex to write, so I would consider using the module as is (and even extending it as needed!). Secondly, I'd like to point out that I'm not doing any orchestration, only config management. Which means this can actually scale! I will take a closer look, maybe I can bite the bullet and implement the few lines of code that are required to make this work in Salt (it would take way too much work and be generally counterproductive to switch to Puppet). Of course I can only help with the puppet case, but if you don't switch (this module is a winning module, in the same way that rails saved ruby, so I would take a closer look) you can at least use it as a reference architecture when writing a salt module. That;s the beauty of Free Software! Good luck! HTH, James -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Minimal permissions for joiner account?
Thanks, that was actually very helpful. Host Enrollment privilege does not actually allow you to enroll hosts, not sure what that is about. But Host Administrators worked just fine. -M On Fri, Aug 15, 2014 at 1:18 AM, Martin Kosek mko...@redhat.com wrote: On 08/14/2014 10:23 PM, Michael Lasevich wrote: Is there somewhere a documented minimum set of permissions required to create a special role/account/principal to auto-join machines to the domain? I am not all too comfortable to run this as admin user and not quite ready to set up the orchestration needed to pre-join the host. Thanks, -M You can simply create a system user or a joiner service and assign it a Host Administrators privilege: # ipa privilege-show Host Administrators Privilege name: Host Administrators Description: Host Administrators Permissions: add hosts, remove hosts, modify hosts, manage host ssh public keys, manage host keytab, enroll a host, retrieve certificates from the ca, revoke certificate, add krbprincipalname to a host Granting privilege to roles: IT Specialist HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA4 OTP vs PAM
Thanks, glad I asked before wasting time. On Fri, Aug 15, 2014 at 1:07 AM, Jakub Hrozek jhro...@redhat.com wrote: On Thu, Aug 14, 2014 at 01:19:58PM -0700, Michael Lasevich wrote: I did not dive into this yet, but before I waste too much time I wanted to ask if centos 6.5 default ipa client expected to work with 2FA or not. No it's not, sorry. The 6.5 client is SSSD 1.9.x and there's a couple of fixes that landed during the 1.11 development such as: https://fedorahosted.org/sssd/ticket/2186 or: https://fedorahosted.org/sssd/ticket/2271 plus some other commits I see in git log which don't reference any ticket. I'd suggest to test using a centos 7.0 client. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] FreeIPA4 OTP vs PAM
I am testing a simple setup with FreeIPA 4.0.1 server and a centos6.5 stock ipa-client package and I can get the regular password to work, but not otp login (otp login works in web ui). As I understood this, kinit is not expected to work (requires FAST) but PAM (which uses sssd, which supposed to supports/configure FAST by default) Indeed the kinit fails with Generic preauthentication failure while getting initial credentials but PAM/SSSD does not seem to work either. This is a brand new test domain with allow-all HBAC intact, so I do not think that is the issue I did not dive into this yet, but before I waste too much time I wanted to ask if centos 6.5 default ipa client expected to work with 2FA or not. Thanks -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Minimal permissions for joiner account?
Is there somewhere a documented minimum set of permissions required to create a special role/account/principal to auto-join machines to the domain? I am not all too comfortable to run this as admin user and not quite ready to set up the orchestration needed to pre-join the host. Thanks, -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Minimal permissions for joiner account?
Not that much. For one, I am using Salt instead if Puppet, but more importantly, if I am reading this correctly it seems to be just using full admin account. I can already do that. By orchestration I meant setting up the OTP for client join on the server, then passing that OTP to the client to join it. It is not that hard to throw together, but timing in this process can be problematic. I prefer to avoid it for the moment if I can and just create a non-admin account for this. On Thu, Aug 14, 2014 at 2:07 PM, James purplei...@gmail.com wrote: On Thu, Aug 14, 2014 at 4:23 PM, Michael Lasevich mlasev...@lasevich.net wrote: I am not all too comfortable to run this as admin user and not quite ready to set up the orchestration needed to pre-join the host. Re: orchestration, https://github.com/purpleidea/puppet-ipa Does this help? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Minimal permissions for joiner account?
I appreciate it. Maybe I did not read it close enough, but it seemed to send the admin password to every client, which is what I am trying to avoid. I will take a closer look, maybe I can bite the bullet and implement the few lines of code that are required to make this work in Salt (it would take way too much work and be generally counterproductive to switch to Puppet). -M On Thu, Aug 14, 2014 at 2:07 PM, James purplei...@gmail.com wrote: On Thu, Aug 14, 2014 at 4:23 PM, Michael Lasevich mlasev...@lasevich.net wrote: I am not all too comfortable to run this as admin user and not quite ready to set up the orchestration needed to pre-join the host. Re: orchestration, https://github.com/purpleidea/puppet-ipa Does this help? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Using Native OTP for auth from specific hosts
Ok, I am trying to figure out how to use native OTP capabilities in FreeIPA4 to authenticate users but I am not finding enough docs on how to USE OTP. Specifically I would like to force OTP authentication on specific servers while allowing password auth in other cases. As I understand authentication, you can either select OTP or password or both authentications, but if you select both, the user can use password instead of otp from ANY server. Is there any way to block password auth based on source (HBAC rules?) So far the only way I can figure out is to create a second account, which is less than optimal. Thanks, -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Using Native OTP for auth from specific hosts
Thanks for quick response, further questions inline. On Mon, Aug 11, 2014 at 11:49 AM, Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 11 Aug 2014, Michael Lasevich wrote: Ok, I am trying to figure out how to use native OTP capabilities in FreeIPA4 to authenticate users but I am not finding enough docs on how to USE OTP. Specifically I would like to force OTP authentication on specific servers while allowing password auth in other cases. As I understand authentication, you can either select OTP or password or both authentications, but if you select both, the user can use password instead of otp from ANY server. That is correct. So, it is NOT intended to use for border-style 2FA authentication (i.e. VPN) - which seems may be a common use case for 2FA? Is there any way to block password auth based on source (HBAC rules?) So far the only way I can figure out is to create a second account, which is less than optimal. No, this functionality is not supported. One particular issue is that we'll need to authenticate before applying HBAC rules, not after, so some other means to validate the request chain are needed. Additionally, Kerberos authentication requires to enter your credentials only when obtaining a ticket granting ticket (TGT) which happens before a client will ask for a ticket to a specific service. Also, renewing the ticket might be possible without original credentials. Perhaps we could add a flag into TGT that would tell how strong were credentials (how many factors were in use) when TGT was obtained and then use it in a policy to see if a ticket to the target service principal could be granted. I think I understand - HBAC has no way to know how you authenticated - so you cannot make rules based on that? Is there a way to test OTP token auth while bypassing kerberos? For example, you can validate user's password via a LDAP login, - can you do a similar validation of OTP token directly? Thanks, -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Using Native OTP for auth from specific hosts
On Mon, Aug 11, 2014 at 12:30 PM, Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 11 Aug 2014, Michael Lasevich wrote: So, it is NOT intended to use for border-style 2FA authentication (i.e. VPN) - which seems may be a common use case for 2FA? You can always supplement authentication check with some host-specific information at the VPN concentrator. We don't have ready to use solution here but it is definitely possible to use such scheme against FreeIPA 2FA. Sorry, I am not following. What do you mean by host-specific information? If system has no way to detect how many factors were involved in authentication, how would I be able to guarantee that only 2FA is allowed via this box? I suppose this can work: I can write code that will: 1 - detects if there are OTP numbers at the end of the password 2 - authenticates using full 2FA 3 - authenticates using just password without 2FA And then authenticate only if all 3 conditions are satisfied. Seems a bit hacky, but that is the only way I can think that may work. Alternative is to set up 2 users for each actual user, one for border and one for internal auth. Force 2fa on border user. Only allow border users on border boxes. Am I missing anything? -M -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Using Native OTP for auth from specific hosts
My thought is that while 2 and 3 are same from IPA point of view, since I am guaranteed to be sending a different credentials in those cases I am guaranteed to be checking both password and otp. Prevents a case where user's password ends in a string of digits similar to OTP. I will look into checking the tokens for changes, but that seems a bit more complicated and error-prone. -M On Mon, Aug 11, 2014 at 1:04 PM, Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 11 Aug 2014, Michael Lasevich wrote: On Mon, Aug 11, 2014 at 12:30 PM, Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 11 Aug 2014, Michael Lasevich wrote: So, it is NOT intended to use for border-style 2FA authentication (i.e. VPN) - which seems may be a common use case for 2FA? You can always supplement authentication check with some host-specific information at the VPN concentrator. We don't have ready to use solution here but it is definitely possible to use such scheme against FreeIPA 2FA. Sorry, I am not following. What do you mean by host-specific information? If system has no way to detect how many factors were involved in authentication, how would I be able to guarantee that only 2FA is allowed via this box? I suppose this can work: I can write code that will: 1 - detects if there are OTP numbers at the end of the password 2 - authenticates using full 2FA 3 - authenticates using just password without 2FA And then authenticate only if all 3 conditions are satisfied. Seems a bit hacky, but that is the only way I can think that may work. 2 and 3 are the same from IPA point of view, just an LDAP bind. Ideally SSSD could handle this as part of a PAM stack by providing PAM feedback that could be used by other modules. There was no request for this functionality before. However, I was mostly thinking that you may have an authentication sequence where past successful auth you would check tokens associated with the user to see if there is a recent update within the same time period on one of tokens. This would work right now, though it is a bit a hack -- a better one than the 2-accounts-per-user. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
