Re: [Freeipa-users] How to turn off RC4 in 389ds???

[Michael Lasevich]

That did it.

Thank you.

On Thu, Sep 24, 2015 at 12:59 AM, Martin Kosek  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] - SSL alert:
> > 

Re: [Freeipa-users] How to turn off RC4 in 389ds???

[Michael Lasevich]

sSSLSupportedCiphers: SSL_RSA_FIPS_WITH_DES_CBC_SHA::DES::SHA1::64
nsSSLSupportedCiphers: TLS_RSA_WITH_DES_CBC_SHA::DES::SHA1::64
nsSSLSupportedCiphers: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA::RC4::SHA1::128
nsSSLSupportedCiphers: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA::DES::SHA1::64
nsSSLSupportedCiphers: TLS_RSA_EXPORT_WITH_RC4_40_MD5::RC4::MD5::128
nsSSLSupportedCiphers: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5::RC2::MD5::128
nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_NULL_SHA::NULL::SHA1::0
nsSSLSupportedCiphers: TLS_ECDHE_RSA_WITH_NULL_SHA::NULL::SHA1::0
nsSSLSupportedCiphers: TLS_ECDH_RSA_WITH_NULL_SHA::NULL::SHA1::0
nsSSLSupportedCiphers: TLS_ECDH_ECDSA_WITH_NULL_SHA::NULL::SHA1::0
nsSSLSupportedCiphers: TLS_RSA_WITH_NULL_SHA::NULL::SHA1::0
nsSSLSupportedCiphers: TLS_RSA_WITH_NULL_SHA256::NULL::SHA256::0
nsSSLSupportedCiphers: TLS_RSA_WITH_NULL_MD5::NULL::MD5::0
nsSSLSupportedCiphers: SSL_CK_RC4_128_WITH_MD5::RC4::MD5::128
nsSSLSupportedCiphers: SSL_CK_RC2_128_CBC_WITH_MD5::RC2::MD5::128
nsSSLSupportedCiphers: SSL_CK_DES_192_EDE3_CBC_WITH_MD5::3DES::MD5::192
nsSSLSupportedCiphers: SSL_CK_DES_64_CBC_WITH_MD5::DES::MD5::64
nsSSLSupportedCiphers: SSL_CK_RC4_128_EXPORT40_WITH_MD5::RC4::MD5::128
nsSSLSupportedCiphers: SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5::RC2::MD5::128
nssslenabledciphers:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::1
 28
nssslenabledciphers:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384::AES-GCM::AEAD::2
 56
nssslenabledciphers:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128
nssslenabledciphers:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384::AES-GCM::AEAD::256
nssslenabledciphers:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384::AES::SHA384::256
nssslenabledciphers: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384::AES::SHA384::256
nssslenabledciphers: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA::AES::SHA1::256
nssslenabledciphers: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA::AES::SHA1::128
nssslenabledciphers: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128
nssslenabledciphers:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128
nssslenabledciphers: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128
nssslenabledciphers: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256
nssslenabledciphers: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128
nssslenabledciphers: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128
nssslenabledciphers: TLS_DHE_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128
nssslenabledciphers: TLS_DHE_DSS_WITH_AES_128_CBC_SHA::AES::SHA1::128
nssslenabledciphers: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128
nssslenabledciphers: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256::AES::SHA256::128
nssslenabledciphers:
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1::12
 8
nssslenabledciphers:
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1::12
 8
nssslenabledciphers: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384::AES-GCM::AEAD::256
nssslenabledciphers: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384::AES-GCM::AEAD::256
nssslenabledciphers: TLS_DHE_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256
nssslenabledciphers: TLS_DHE_DSS_WITH_AES_256_CBC_SHA::AES::SHA1::256
nssslenabledciphers: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256::AES::SHA256::256
nssslenabledciphers: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256::AES::SHA256::256
nssslenabledciphers:
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1::25
 6
nssslenabledciphers:
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1::25
 6
nssslenabledciphers: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA::AES::SHA1::128
nssslenabledciphers: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128
nssslenabledciphers: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA::AES::SHA1::256
nssslenabledciphers: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256
nssslenabledciphers: TLS_RSA_WITH_AES_256_GCM_SHA384::AES-GCM::SHA384::256
nssslenabledciphers: TLS_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128
nssslenabledciphers: TLS_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128
nssslenabledciphers: TLS_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128
nssslenabledciphers: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1::128
nssslenabledciphers: TLS_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256
nssslenabledciphers: TLS_RSA_WITH_AES_256_CBC_SHA256::AES::SHA256::256
nssslenabledciphers: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1::256
nssslenabledciphers: TLS_RSA_WITH_SEED_CBC_SHA::SEED::SHA1::128
nsTLS1: on
sslVersionMax: TLS1.2

# RSA, encryption, config
dn: cn=RSA,cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionModule
nsSSLPersonalitySSL: Server-Cert
nsSSLActivation: on
cn: RSA
nsSSLToken: internal (software)

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2


On Wed, Sep 23, 2015 at 11:53 AM, Martin Kosek  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...).
>>
>
> You would not be the first to do it :-)
>
> I am running

Re: [Freeipa-users] How to turn off RC4 in 389ds???

[Michael Lasevich]

  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


On Wed, Sep 23, 2015 at 8:19 AM, Ludwig Krispenz 
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  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 

Re: [Freeipa-users] How to turn off RC4 in 389ds???

[Michael Lasevich]

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  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

[Freeipa-users] OTP unstable/non functional after upgrade?

[Michael Lasevich]

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

[Freeipa-users] How to turn off RC4 in 389ds???

[Michael Lasevich]

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

[Freeipa-users] Possible bug in ipa-replica-install/pkispawn - or maybe lib mismatch

[Michael Lasevich]

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

Re: [Freeipa-users] Saltstack and ipa-install on Centos7 failing

[Michael Lasevich]

Is SELinux on?
On Mar 13, 2015 7:46 AM, "Andrew Holway"  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.clou

Re: [Freeipa-users] Fwd: 2-Factor and services

[Michael Lasevich]

There is actually a way to achieve what you most likely want to but not
what you are asking for.

I do not think there is currently a way to force 2fa based on service or
host being authenticated - it is all or nothing. However, if all you want
is ability to use 2fa against FreeIPA for OpenVPN authentication and use
just password everywhere else - that is actually possible.

This is how I achieved this - may not be an ideal setup but it works. As
suggested, set up users to support both 2fa and password authentication.
Forget about using PAM for OpenVPN authentication - instead use a plug-in
script with credentials passed using via-env. You can write the plugin in
any language you want (I used Python) and your logic should be something
along the lines of:

Parse password to separate OTP token from password. Use LDAP to
authenticate with just password and then again with password AND OTP token.
LDAP authentication happens on the IPA server and will support both
methods.  Authenticating twice is important to guarantee you do not have a
smart-alec user who sets their password to end in 6 digits instead of
actually enabling 2fa. Once you have successful authentication, you can use
it to perform additional verifications - like checking membership(or lack
thereof) in specific group, etc., etc.

So, here is something else to think about. You may not want to allow the
same accounts access to VPN and to the internal network. There is a reason
why this is generally considered a bad practice. If someone, by some means
(say another heartbleed-like exploit or some MITM attack or by gaining root
access to the VPN serve) gains access to your user's VPN login credentials
- the last thing you want is them having a full run of the network using
those exact same credentials. Ideally it would be nice if 2fa "pin" (the
non OTP portion of the 2fa) would be DIFFERENT from the password on the
same account, but FreeIPA does not support that - at least not at this
time. So what I would recommend is using a completely separate account in
FreeIPA for VPN access.  You can standardize this by using a standard
prefix (so that for example user "username" would have an "ext-username"
account for 2fa use with external authentication) - "ext" account would
have no permissions to any data or internal login, just to access the
network  from outside and the main account would have no external access.
To hack you, someone would then need to hack your OpenVPN box and then
would still need to hack your internal authentication - which should be
encrypted by TLS/SSH even over the VPN. You can also add the prefix
automatically behind the scenes with the OpenVPN authentication script, as
well as have the script only allow access for accounts that have no other
privileges besides external access. Something to think about.

HTH,

-M

On Sun, Mar 1, 2015 at 6:40 PM, Dmitri Pal  wrote:

> On 02/27/2015 11:37 AM, Matt Wells wrote:
>
>> I see how that would work but as you mentioned, I no longer have SSO.
>>
>> My desktops are all 3.  Linux, Mac and Windows however the Windows
>> systems talk with AD and a trust exists to facilitate those
>> communications and SSO between the systems.
>>
>> It doesn't sound like this is really possible without the heavy loss
>> of functionality.  This would be an amazing option to add though.  The
>> ability to define a service and prioritize an authentication
>> mechanism.
>>
>
> On Mac and Windows you would not get SSO anyways because Kerberos on thos
> platforms does not support latest RFCs related to 2FA at least yet and
> since they are proprietary it is unclear what their plans are.
>
> The problem we also have is that there is no way to be selective on the
> KDC/DS side - there is no way to determine what the client is and associate
> some policies to it.
> It would have to be the client that would have to have capability to
> enforce or not enforce 2FA if the server supports both. But again that
> means that Mac and Windows would have to keep up with this capability.
>
> Bottom line it is a popular request but it is unclear how we can satisfy
> it.
>
>
>
>>
>> On Thu, Feb 26, 2015 at 2:09 PM, Dmitri Pal  wrote:
>>
>>> On 02/26/2015 12:40 PM, Matt Wells wrote:
>>>
 Had an error on my options for the list and the replies failed to get
 to me. We'll see if this reply works.  :)

 @Dmitri - Anyone coming through this service/host (OpenVPN with pam)
 will be required to use 2-Factor.  Their normal logins at their desk
 are not required for 2-factor, it's ok if they use it but it's not
 required at all.
 This VPN service is as assumed, exposed to the internet.  We're
 wanting to protect ourselves as best we can with AAA.

>>>
>>> If we just talking about managing users in IdM and having tokens for them
>>> managed in IdM too then the recommendation is:
>>>
>>> - Set users to use OTP or password (set both check boxes)
>>> - Configure VPN to use Kerberos authentication against IPA - t

Re: [Freeipa-users] Where and how are passwords stored?

[Michael Lasevich]

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"  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?

[Michael Lasevich]

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

[Michael Lasevich]

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

[Michael Lasevich]

b] (0x4000): [2451] 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 
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 
> wrote:
>
>> Thanks, glad I asked before wasting time.
>>
>>
>> On Fri, Aug 15, 2014 at 1:07 AM, Jakub Hrozek  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

[Michael Lasevich]

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 
wrote:

> Thanks, glad I asked before wasting time.
>
>
> On Fri, Aug 15, 2014 at 1:07 AM, Jakub Hrozek  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

[Michael Lasevich]

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

[Michael Lasevich]

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

[Michael Lasevich]

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 
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  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

[Michael Lasevich]

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  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

[Freeipa-users] IPA Backup in AWS - best practices?

[Michael Lasevich]

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] Errors upgrading 4.0.1 to 4.1

[Michael Lasevich]

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

Re: [Freeipa-users] Errors upgrading 4.0.1 to 4.1

[Michael Lasevich]

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

[Michael Lasevich]

*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=
>>>>>> 2014-10-28T05:01:24Z DEBUG Traceback (most recent call last):
>

Re: [Freeipa-users] F20 Problem upgrading to 4.1

[Michael Lasevich]

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=
>>>> 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()
>>

Re: [Freeipa-users] F20 Problem upgrading to 4.1

[Michael Lasevich]

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=
>> 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

[Michael Lasevich]

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=
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 > >:
>>
>> 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 >> >:
>>>
>>> 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 &

Re: [Freeipa-users] Inconsistent group memberships in sssd

[Michael Lasevich]

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"  wrote:

> On Thu, Oct 23, 2014 at 05:19:38PM -0700, Michael Lasevich wrote:
> > Small update, it appears that once I run "getent group " - my
> > user shows up in the group . 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] Errors upgrading 4.0.1 to 4.1

[Michael Lasevich]

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] Inconsistent group memberships in sssd

[Michael Lasevich]

Small update, it appears that once I run "getent group " - my
user shows up in the group . Odd.

(and yes, I have ran "sss_cache -UG" many a time)

-M

On Thu, Oct 23, 2014 at 5:15 PM, Michael Lasevich 
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 " - 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] Inconsistent group memberships in sssd

[Michael Lasevich]

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 " - 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] DNS: Possible to set a CNAME for bare domain?

[Michael Lasevich]

You cannot have cname for a bare domain in IPA or in any DNS service, it
violates DNS rfc's.
On Oct 4, 2014 10:19 AM, "Will Sheldon"  wrote:

>
> Hello everyone : )
>
>
> Is it possible to configure a CNAME for a bare domain with freeIPA?
>
> We would like to move our site over to an Amazon ELB, but to do so we have
> to point our domain (foo.com, not www.foo.com) at an was A record with a
> CNAME (something like .eu-west-1.elb.amazonaws.com)
>
> This is technically possible, but IPA complains:
>
> "invalid 'cnamerecord': CNAME record is not allowed to coexist with any
> other records except PTR"
>
> I’m guessing this is because of the @ NS record.
>
>
> Is there any way to override this behaviour? Can I make manual
> modifications to the zone file?
>
>
>
>
> Will Sheldon
>
>
> --
> 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] Use of SAN's with automatic certificates in FreeIPA 4

[Michael Lasevich]

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  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  is the first SAN):
> >>
> >> ** ipa: ERROR: The service principal for subject alt name  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=MKOS

Re: [Freeipa-users] Use of SAN's with automatic certificates in FreeIPA 4

[Michael Lasevich]

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  is the first SAN):

** ipa: ERROR: The service principal for subject alt name  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  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

[Michael Lasevich]

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

[Freeipa-users] Ubuntu 3.3.x client vs. 3.0.0 server

[Michael Lasevich]

Trying to use ipa command line admin tools from Ubuntu 14.04 box against
3.0.0 CentOS 6 server and running into trouble.

Seems like upgrading server is not an option without upgrading the server,
and 3.3.0 client is not compatible with 3.0.0 server (seems to be sending
invalid fields to the server in api)

I cannot seem to easily find a way to get 3.0 client on ubuntu not do I see
any pre-made 3.0 deb packages.

Any suggestions?

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?

[Michael Lasevich]

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  wrote:

> On 08/15/2014 06:02 PM, James wrote:
>
>> On Fri, Aug 15, 2014 at 5:25 AM, Michael Lasevich
>>  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] FreeIPA4 OTP vs PAM

[Michael Lasevich]

Thanks, glad I asked before wasting time.


On Fri, Aug 15, 2014 at 1:07 AM, Jakub Hrozek  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] Minimal permissions for "joiner" account?

[Michael Lasevich]

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  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] Minimal permissions for "joiner" account?

[Michael Lasevich]

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  wrote:

> On Thu, Aug 14, 2014 at 8:29 PM, Michael Lasevich
>  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?

[Michael Lasevich]

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  wrote:
>
> On Thu, Aug 14, 2014 at 4:23 PM, Michael Lasevich
>  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?

[Michael Lasevich]

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  wrote:

> On Thu, Aug 14, 2014 at 4:23 PM, Michael Lasevich
>  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] Minimal permissions for "joiner" account?

[Michael Lasevich]

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

[Freeipa-users] FreeIPA4 OTP vs PAM

[Michael Lasevich]

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

Re: [Freeipa-users] Using Native OTP for auth from specific hosts

[Michael Lasevich]

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 
wrote:

> On Mon, 11 Aug 2014, Michael Lasevich wrote:
>
>> On Mon, Aug 11, 2014 at 12:30 PM, Alexander Bokovoy 
>> 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

Re: [Freeipa-users] Using Native OTP for auth from specific hosts

[Michael Lasevich]

On Mon, Aug 11, 2014 at 12:30 PM, Alexander Bokovoy 
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

[Michael Lasevich]

Thanks for quick response, further questions inline.


On Mon, Aug 11, 2014 at 11:49 AM, Alexander Bokovoy 
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

[Freeipa-users] Using Native OTP for auth from specific hosts

[Michael Lasevich]

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