Re: [Freeipa-users] Automatic IPA CA cert generation

[James Masson]

On 23/09/15 11:03, Fraser Tweedale wrote:

On Wed, Sep 23, 2015 at 09:09:25AM +0200, David Kupka wrote:

On 22/09/15 17:02, James Masson wrote:


Hi,

we're building IPAs in an automated fashion, for environments that get
created and destroyed a lot. At the moment, the CA certs used inside
these IPAs are self-signed, as part of the normal "ipa-server-install"
setup process.

We would like to switch to issuing signed intermediate CA certs to the
IPAs we deploy.

The documentation lists the two part process necessary for this. First
"--external-ca" - and then "--external-cert-file"

Are there any ways to skip this, and give the setup process a known
public/private key+cert up front? I'm hoping to avoid the need to have
to use/send this automatically generated CSR every time.

thanks

James M



Hello James,
currently it's not possible but making installation with externally signed
CA single step sounds really useful to me.
Currently certmonger is generating the CSR for FreeIPA server in the first
step of installation. Certmonger is also able to send certificate to
external CA for signing.

I'm not sure if we could combine these two cermonger's abilities right now
but if not it shouldn't be difficult to add functionality to certmonger to
send the CSR to preconfigured CA instead of just storing it in file.

This would of course require configuring the certmonger with information
about the CA before FreeIPA server installation but it's just one command
(getcert-add-ca).

Could you please file a ticket (https://fedorahosted.org/freeipa/newticket)?


There are two sides to this - one is using Certmonger for automatic
signing of intermediate CA certificate to be used by IPA, the other
is simply using a CA cert that the administrator already possesses,
e.g. in a PKCS #12 file.  These should be separate tickets.

Cheers,
Fraser


--
David Kupka

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


Done -

https://fedorahosted.org/freeipa/ticket/5317
https://fedorahosted.org/freeipa/ticket/5318

Would it be possible to use Certmonger to help the 2 step process used 
at the moment?


ie. run 'ipa-server-install' the first time - get the CSR
use local Certmonger to handle the CSR submission to upstream CA
use the resulting Cert in the second 'ipa-server-install'

Any pointers?

regards

James M





--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

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

[Martin Kosek]

On 09/23/2015 11:00 AM, Michael Lasevich wrote:
> OK, this is most bizarre issue,
> 
> I am trying to disable RC4 based TLS Cipher Suites in LDAPs(port 636) and
> for the life of me cannot get it to work
> 
> I have followed many nearly identical instructions to create ldif file and
> change "nsSSL3Ciphers" in "cn=encryption,cn=config". Seems simple enough -
> and I get it to take, and during the startup I can see the right SSL Cipher
> Suites listed in errors.log - but when it starts and I probe it, RC4
> ciphers are still there. I am completely confused.
> 
> I tried setting "nsSSL3Ciphers" to "default" (which does not have "RC4")
> and to old style cyphers lists(lowercase), and new style cypher
> lists(uppercase), and nothing seems to make any difference.
> 
> Any ideas?
> 
> -M

Are you asking about standalone 389-DS or the one integrated in FreeIPA? As
with currently supported versions of FreeIPA, RC4 ciphers should be already
gone, AFAIK.

In RHEL/CentOS world, it should be fixed in 6.7/7.1 or later:

https://bugzilla.redhat.com/show_bug.cgi?id=1154687
https://fedorahosted.org/freeipa/ticket/4653

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Automatic IPA CA cert generation

[Fraser Tweedale]

On Wed, Sep 23, 2015 at 09:09:25AM +0200, David Kupka wrote:
> On 22/09/15 17:02, James Masson wrote:
> >
> >Hi,
> >
> >we're building IPAs in an automated fashion, for environments that get
> >created and destroyed a lot. At the moment, the CA certs used inside
> >these IPAs are self-signed, as part of the normal "ipa-server-install"
> >setup process.
> >
> >We would like to switch to issuing signed intermediate CA certs to the
> >IPAs we deploy.
> >
> >The documentation lists the two part process necessary for this. First
> >"--external-ca" - and then "--external-cert-file"
> >
> >Are there any ways to skip this, and give the setup process a known
> >public/private key+cert up front? I'm hoping to avoid the need to have
> >to use/send this automatically generated CSR every time.
> >
> >thanks
> >
> >James M
> >
> 
> Hello James,
> currently it's not possible but making installation with externally signed
> CA single step sounds really useful to me.
> Currently certmonger is generating the CSR for FreeIPA server in the first
> step of installation. Certmonger is also able to send certificate to
> external CA for signing.
> 
> I'm not sure if we could combine these two cermonger's abilities right now
> but if not it shouldn't be difficult to add functionality to certmonger to
> send the CSR to preconfigured CA instead of just storing it in file.
> 
> This would of course require configuring the certmonger with information
> about the CA before FreeIPA server installation but it's just one command
> (getcert-add-ca).
> 
> Could you please file a ticket (https://fedorahosted.org/freeipa/newticket)?
> 
There are two sides to this - one is using Certmonger for automatic
signing of intermediate CA certificate to be used by IPA, the other
is simply using a CA cert that the administrator already possesses,
e.g. in a PKCS #12 file.  These should be separate tickets.

Cheers,
Fraser

> -- 
> David Kupka
> 
> -- 
> 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] [Import existing CA Cert]

[Michael Anderson]

Hi Martin,

thanks for your reply.

On 09/23/2015 09:07 AM, Martin Kosek wrote:

On 09/22/2015 12:41 PM, Michael Anderson wrote:

  Hi All,

we're evaluation freeipa/dogtag as a pki management service and hoping to
replace our existing menagerie of bash/openssl scripts. I'm trying to establish
a migration path for our existing pki solution and have a few questions:

Hi Michael,

Before you continue with the project, please keep in mind that FreeIPA PKI
capabilities are bound to the FreeIPA objects - i.e. users, hosts or services.
It does not allow you to generate completely random certificates (at the 
moment).


Does that mean that I can only generate certificates for hosts running 
the client software? What I'd really like to be able to do is automate 
Apache/Nginx SSL cert generation for our dev/continuous-delivery 
infrastructure. So I'd like to have two or three signing CA's for dev, 
staging and prod and automate CSR creation, signing and deployment. Is 
this feasible with freeipa?





'* how can I import and use our existing CA signing cert?
* can I import existing server certs and keys?

Could you create FreeIPA server CA as subordinate CA to your current CA? To me,
it seems the easiest way as I do not think we have some nice CLIs to inject
existing CA cert+key to FreeIPA/Dogtag. CCing Jan and Fraser to see if they
have an idea.

More here:
http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructurell


With my current project I'll be rebuilding a lot of stuff, so starting 
fresh with a new freeipa-generated signing cert won't be such a problem. 
That said, it seems to me that the ability to import and use an existing 
signing cert would lower the adoption threshold for new users.





* I'm using Fedora22. When I install dogtag-pki, the user page for submitting
csr's is available. But when I install the freeipa package, I get a 404 when
attempting to access the page. Is this functionality available in freeipa?

When PKI is configured as part of FreeIPA, FreeIPA takes control of requesting
and passing the certificates from/to user. I think the Dogtag UI should be
still somehow accessible, but is not the supported way.

FreeIPA itself can accept CSRs via cert-request CLI command or Web UI page, or
via certmonger (man ipa-getcert) component that even renews the certificate.

BTW, what version of FreeIPA are you using? FreeIPA 4.2 provides much more PKI
related capabilities than older versions, for beginning Certificate Profiles,
which are a must if you do not want to use just single fixed cert profile.


I'm using the version packaged with Fedora 22, 4.1.4



More here:
http://www.freeipa.org/page/Releases/4.2.0

Martin


--
--
Michael Anderson
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96  michael.anderson at elegosoft.com
fax   +49 30 23 45 86 95  http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht
Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194

--
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] [Import existing CA Cert]

[Fraser Tweedale]

On Wed, Sep 23, 2015 at 09:07:31AM +0200, Martin Kosek wrote:
> On 09/22/2015 12:41 PM, Michael Anderson wrote:
> > Hi All,
> > 
> > we're evaluation freeipa/dogtag as a pki management service and hoping to
> > replace our existing menagerie of bash/openssl scripts. I'm trying to 
> > establish
> > a migration path for our existing pki solution and have a few questions:
> 
> Hi Michael,
> 
> Before you continue with the project, please keep in mind that FreeIPA PKI
> capabilities are bound to the FreeIPA objects - i.e. users, hosts or services.
> It does not allow you to generate completely random certificates (at the 
> moment).
> 
> > * how can I import and use our existing CA signing cert?
> > * can I import existing server certs and keys?
> 
> Could you create FreeIPA server CA as subordinate CA to your current CA? To 
> me,
> it seems the easiest way as I do not think we have some nice CLIs to inject
> existing CA cert+key to FreeIPA/Dogtag. CCing Jan and Fraser to see if they
> have an idea.
> 
Indeed, there does not seem to be a supported way to do this but you
are not the only one asking for it (another thread on freeipa-users
today asks the same question).  So it is worth filing a ticket if
there is not one already.

For a workaround, you could probably do it by overwriting a keypair
in the nssdb in between step 1 and step 2 of ipa-server-install; it
is a nasty hack and I have not tried it, but it is my only idea
right now.

> More here:
> http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure
> 
> > * I'm using Fedora22. When I install dogtag-pki, the user page for 
> > submitting
> > csr's is available. But when I install the freeipa package, I get a 404 when
> > attempting to access the page. Is this functionality available in freeipa?
> 
> When PKI is configured as part of FreeIPA, FreeIPA takes control of requesting
> and passing the certificates from/to user. I think the Dogtag UI should be
> still somehow accessible, but is not the supported way.
> 
It should be accessible on ports 8080 / 8443, i.e.
https://your.domain:8443/ca/ee/ca.  The full power of Dogtag is
available to you, but as stated it is not the supported way, and if
FreeIPA itself does not solve your certifiate use cases, please make
sure we know about them so we can determine whether we should
support it in FreeIPA directly.

Cheers,
Fraser

> FreeIPA itself can accept CSRs via cert-request CLI command or Web UI page, or
> via certmonger (man ipa-getcert) component that even renews the certificate.
> 
> BTW, what version of FreeIPA are you using? FreeIPA 4.2 provides much more PKI
> related capabilities than older versions, for beginning Certificate Profiles,
> which are a must if you do not want to use just single fixed cert profile.
> 
> More here:
> http://www.freeipa.org/page/Releases/4.2.0
> 
> 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

[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

Re: [Freeipa-users] Automatic IPA CA cert generation

[Rob Crittenden]

David Kupka wrote:
> On 22/09/15 17:02, James Masson wrote:
>>
>> Hi,
>>
>> we're building IPAs in an automated fashion, for environments that get
>> created and destroyed a lot. At the moment, the CA certs used inside
>> these IPAs are self-signed, as part of the normal "ipa-server-install"
>> setup process.
>>
>> We would like to switch to issuing signed intermediate CA certs to the
>> IPAs we deploy.
>>
>> The documentation lists the two part process necessary for this. First
>> "--external-ca" - and then "--external-cert-file"
>>
>> Are there any ways to skip this, and give the setup process a known
>> public/private key+cert up front? I'm hoping to avoid the need to have
>> to use/send this automatically generated CSR every time.
>>
>> thanks
>>
>> James M
>>
> 
> Hello James,
> currently it's not possible but making installation with externally
> signed CA single step sounds really useful to me.
> Currently certmonger is generating the CSR for FreeIPA server in the
> first step of installation. Certmonger is also able to send certificate
> to external CA for signing.
> 
> I'm not sure if we could combine these two cermonger's abilities right
> now but if not it shouldn't be difficult to add functionality to
> certmonger to send the CSR to preconfigured CA instead of just storing
> it in file.
> 
> This would of course require configuring the certmonger with information
> about the CA before FreeIPA server installation but it's just one
> command (getcert-add-ca).
> 
> Could you please file a ticket
> (https://fedorahosted.org/freeipa/newticket)?
> 

Unless something has radically changed AFAIK dogtag generates its own
keys and certmonger simply tracks the cert it issues after-the-fact.
There may be room there to use certmonger with sub-CAs since those are
really just separate profiles, but for the initial install I don't
believe certmonger is used.

rob

-- 
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] User, keytab, password and ldap

[bahan w]

Hello !

I'm using IPA 3.0.0 and I have a problem with one of the user I created.
user3

I created this user with the command ipa user-add without specifying any
password.
Then I performed an ipa-getkeytab command with the -P option to have a
keytab and a password.

When I check the ldap server with the following command, I cannot find any
"userpassword" field for this user.
ldapsearch -v -x -D 'cn=Directory Manager' -W -h  -p 

###
# user3, users, accounts, myrealm
dn: uid=user3,cn=users,cn=accounts,dc=myrealm
displayName: user3 user3
cn: user3 user3
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
loginShell: /bin/sh
sn: user3
gecos: user3 user3
homeDirectory: /home/user3
krbPwdPolicyReference: cn=pwp_users,cn=MYREALM,cn=kerberos,dc=myrealm
krbPrincipalName: user3@MYREALM
givenName: user3
uid: user3
initials: uu
ipaUniqueID: 5dbc0e78-5884-11e5-a8a0-00505695d2c7
uidNumber: 
gidNumber: 
memberOf: cn=defaultgroup,cn=groups,cn=accounts,dc=myrealm
memberOf: cn=pwp_users,cn=groups,cn=accounts,dc=myrealm
mepManagedEntry: cn=user3,cn=groups,cn=accounts,dc=myrealm
krbLastPwdChange: 20150923134438Z
krbPrincipalKey:: 
krbExtraData:: AALGrAJWYV9hcHBfcmpkbUBCREZJTlQxAA==
krbLastSuccessfulAuth: 20150923120752Z
krbLastFailedAuth: 20150923132257Z
krbLoginFailedCount: 1
###

Then, with an admin ticket, I performed an ipa passwd user3 and I set a one
time password.
Then I connected with user3 and he was able to change its one time password
into something else.
And when I retried the ldapsearch command, the field userpassword was there.
But the keytab is not working anymore.

So here is my question :
How can I generate a user with a keytab, a password and the userpassword
field in the ldap ?

The ipa-getkeytab -P option allows me to have both keytab and the password,
but as the field userpassword is missing in the ldap, some other tools
using ldapbackend authentication does not work for this user.

Best regards.

Bahan
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

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

[Ludwig Krispenz]

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

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] When changing passwords gui displays Login screen is showing

[Andrew Holway]

Hi,

When a user changes their password the ipa gui briefly redirects to a login
page. The user often has an impulse to click on the login button which, on
occasion, can seem to cause a mess with the password change.

Anyone else aware of this behaviour?

ta

Andrew
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

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

[Michael Lasevich]

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:
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled
[23/Sep/2015:09:37:29 -0600] - SSL alert:
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled
[23/Sep/2015:09:37:29 -0600] - SSL alert:
TLS_RSA_WITH_AES_256_GCM_SHA384: enabled
[23/Sep/2015:09:37:29 -0600] - SSL alert:
TLS_RSA_WITH_AES_128_GCM_SHA256: enabled
[23/Sep/2015:09:37:29 -0600] - SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA: enabled
[23/Sep/2015:09:37:29 -0600] - SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA256: enabled
[23/Sep/2015:09:37:29 -0600] - SSL alert:
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled
[23/Sep/2015:09:37:29 -0600] - SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA: enabled
[23/Sep/2015:09:37:29 -0600] - SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA256: enabled
[23/Sep/2015:09:37:29 -0600] - SSL alert:
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled
[23/Sep/2015:09:37:29 -0600] - SSL alert:   TLS_RSA_WITH_SEED_CBC_SHA:
enabled
[23/Sep/2015:09:37:29 -0600] - 389-Directory/1.3.3.8 B2015.040.128 starting
up

SSLScan Output:

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  

[Freeipa-users] Ghost user?

[Janelle]

I have a user I created for testing, but now shows as both "there" but 
not there..


*ipa user-show jtest*

 ipa: ERROR: jtest: user not found

*ipa user-find jtest*
--
1 user matched
--
  User login: jtest
  First name: janelle
  Last name: test
  Home directory: /home/jtest
  Login shell: /bin/bash
  Email address: jt...@example.com
  UID: 1372025403
  GID: 1372025403
  Account disabled: False
  Password: True
  Kerberos keys available: True

*ipa user-del jtest*
 ipa: ERROR: jtest: user not found

*ipa user-add jtest*
First name: janelle
Last name: jtest
ipa: ERROR: user with name "jtest" already exists


I am officially baffled. Any ideas?
~Janelle

-- 
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] Ghost user?

[Martin Basti]

On 09/23/2015 07:15 PM, Janelle wrote:
I have a user I created for testing, but now shows as both "there" but 
not there..


*ipa user-show jtest*

 ipa: ERROR: jtest: user not found

*ipa user-find jtest*
--
1 user matched
--
  User login: jtest
  First name: janelle
  Last name: test
  Home directory: /home/jtest
  Login shell: /bin/bash
  Email address: jt...@example.com
  UID: 1372025403
  GID: 1372025403
  Account disabled: False
  Password: True
  Kerberos keys available: True

*ipa user-del jtest*
 ipa: ERROR: jtest: user not found

*ipa user-add jtest*
First name: janelle
Last name: jtest
ipa: ERROR: user with name "jtest" already exists


I am officially baffled. Any ideas?
~Janelle





Hello,

can you please check directly with LDAP search, if it is replication 
conflict?


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

[Freeipa-users] sssd public socket error

[Andy Thompson]

On one of my servers I'm getting

Sep 23 13:35:07 mdhixuatisamw03 sshd[8136]: pam_unix(sshd:session): session 
opened for user user by (uid=0)
Sep 23 13:35:07 mdhixuatisamw03 sshd[8164]: pam_sss(sshd:setcred): Request to 
sssd failed. Public socket has wrong ownership or permissions.

Authentication still works but group name lookups fail on the server.

Haven't been able to track down yet what config is different on this server and 
I can't find any information on this, anyone have any thoughts?

Thanks

-andy



*** This communication may contain privileged and/or confidential information. 
It is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. ***


-- 
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] Ghost user?

[Rob Crittenden]

Janelle wrote:
> On 9/23/15 10:36 AM, Martin Basti wrote:
>>
>>
>> On 09/23/2015 07:15 PM, Janelle wrote:
>>> I have a user I created for testing, but now shows as both "there"
>>> but not there..
>>>
>>> *ipa user-show jtest*
>>>
>>>  ipa: ERROR: jtest: user not found
>>>
>>> *ipa user-find jtest*
>>> --
>>> 1 user matched
>>> --
>>>   User login: jtest
>>>   First name: janelle
>>>   Last name: test
>>>   Home directory: /home/jtest
>>>   Login shell: /bin/bash
>>>   Email address: jt...@example.com
>>>   UID: 1372025403
>>>   GID: 1372025403
>>>   Account disabled: False
>>>   Password: True
>>>   Kerberos keys available: True
>>>
>>> *ipa user-del jtest*
>>>  ipa: ERROR: jtest: user not found
>>>
>>> *ipa user-add jtest*
>>> First name: janelle
>>> Last name: jtest
>>> ipa: ERROR: user with name "jtest" already exists
>>>
>>>
>>> I am officially baffled. Any ideas?
>>> ~Janelle
>>>
>>>
>>>
>>
>> Hello,
>>
>> can you please check directly with LDAP search, if it is replication
>> conflict?
>>
>> Martin
> I am not sure what I am looking for to determine the replication
> conflict you speak of. I know how to use ldapsearch, but not sure what
> you want to see. 

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

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

[Martin Kosek]

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


Something is really strange here. We need to see settings in 
"cn=encryption,cn=config" to investigate further.


$ ldapsearch -h ipa.example.com -b cn=encryption,cn=config -D "cn=Directory 
Manager" -x -W


should be a good start to give this information. nsSSL3Ciphers for example 
should be set to "+all" and "allowWeakCipher" to off, as per


http://fedorahosted.org/freeipa/ticket/4395


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 

[Freeipa-users] dns_lookup_kdc question

[Aly Khimji]

Hey guys,

Quick question. Just running through a poc and ran into a question.

I have a simple AD DC (win2k8r2 box) with a trust setup to our IPA server.
Trust and all is setup properly and I can see users on the client/ipa
server and on the ipa server I can ssh into it with the AD user.

I am finding that users are unable to log into the "client nodes" and are
getting a "4: System Error" failure in the ssh log. When I dig into the
sssd in debug mode I can see its failing to find KDC for the "realm". Makes
sense so far. So I enable dns_lookup_kdc = true and now it is able to find
the realm and login is successful.

My question is, this "dns_lookup_kdc = true" required in any setup with
AD/IPA trust + ssh into IPA client with AD users?

I am wondering as there may be a use case where the AD server is in another
network and IPA clients won't have direct access to AD. I was wondering if
there is any model in which the client only ever talks to IPA server and
all the AD/Kerbos communication is handled via the IPA server and if so how
is this done?
I have read a bit and this looks as though what I am doing here is a
"legacy" setup. Just wondering if this is different in sssd 1.9 or if kdc =
True is always required.

I am not doing anything extra on the client other then the ipa-client
install.
No manual adjustment of sssd.conf or krb5.conf. If I am missing something
please advise.

Thanks guys

Aly


SW info:

Server
ipa-admintools-4.1.0-18.el7.centos.4.x86_64
ipa-python-4.1.0-18.el7.centos.4.x86_64
ipa-client-4.1.0-18.el7.centos.4.x86_64
ipa-server-trust-ad-4.1.0-18.el7.centos.4.x86_64
ipa-server-4.1.0-18.el7.centos.4.x86_64


el7 Client
sssd-client-1.12.2-58.el7_1.17.x86_64
sssd-common-1.12.2-58.el7_1.17.x86_64
sssd-ad-1.12.2-58.el7_1.17.x86_64
sssd-proxy-1.12.2-58.el7_1.17.x86_64
sssd-krb5-1.12.2-58.el7_1.17.x86_64
ipa-python-4.1.0-18.el7.centos.4.x86_64
sssd-krb5-common-1.12.2-58.el7_1.17.x86_64
sssd-common-pac-1.12.2-58.el7_1.17.x86_64
sssd-ipa-1.12.2-58.el7_1.17.x86_64
sssd-ldap-1.12.2-58.el7_1.17.x86_64
sssd-1.12.2-58.el7_1.17.x86_64
ipa-client-4.1.0-18.el7.centos.4.x86_64

el6 client
sssd-common-1.12.4-47.el6.x86_64
sssd-proxy-1.12.4-47.el6.x86_64
sssd-krb5-common-1.12.4-47.el6.x86_64
sssd-ad-1.12.4-47.el6.x86_64
sssd-1.12.4-47.el6.x86_64
ipa-python-3.0.0-47.el6.centos.x86_64
sssd-client-1.12.4-47.el6.x86_64
sssd-ipa-1.12.4-47.el6.x86_64
sssd-krb5-1.12.4-47.el6.x86_64
ipa-client-3.0.0-47.el6.centos.x86_64
sssd-common-pac-1.12.4-47.el6.x86_64
sssd-ldap-1.12.4-47.el6.x86_64
-- 
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] [Import existing CA Cert]

[Martin Kosek]

On 09/22/2015 12:41 PM, Michael Anderson wrote:
> Hi All,
> 
> we're evaluation freeipa/dogtag as a pki management service and hoping to
> replace our existing menagerie of bash/openssl scripts. I'm trying to 
> establish
> a migration path for our existing pki solution and have a few questions:

Hi Michael,

Before you continue with the project, please keep in mind that FreeIPA PKI
capabilities are bound to the FreeIPA objects - i.e. users, hosts or services.
It does not allow you to generate completely random certificates (at the 
moment).

> * how can I import and use our existing CA signing cert?
> * can I import existing server certs and keys?

Could you create FreeIPA server CA as subordinate CA to your current CA? To me,
it seems the easiest way as I do not think we have some nice CLIs to inject
existing CA cert+key to FreeIPA/Dogtag. CCing Jan and Fraser to see if they
have an idea.

More here:
http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure

> * I'm using Fedora22. When I install dogtag-pki, the user page for submitting
> csr's is available. But when I install the freeipa package, I get a 404 when
> attempting to access the page. Is this functionality available in freeipa?

When PKI is configured as part of FreeIPA, FreeIPA takes control of requesting
and passing the certificates from/to user. I think the Dogtag UI should be
still somehow accessible, but is not the supported way.

FreeIPA itself can accept CSRs via cert-request CLI command or Web UI page, or
via certmonger (man ipa-getcert) component that even renews the certificate.

BTW, what version of FreeIPA are you using? FreeIPA 4.2 provides much more PKI
related capabilities than older versions, for beginning Certificate Profiles,
which are a must if you do not want to use just single fixed cert profile.

More here:
http://www.freeipa.org/page/Releases/4.2.0

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] otp issue: can't log in with password+otp

[Martin Kosek]

On a related point to this note - Duncan, did you try to run your setup with
RPM version of FreeIPA? FreeIPA 4.2 is included both in RHEL-7.2 Beta or in
Fedora 23 Beta updates-testing repo, so you can try the latest and greatest
version there and thus find out if the problems you are seeing are specific to
the containerization or rather a general issue.

On 09/22/2015 08:12 PM, Nathaniel McCallum wrote:
> Running IPA in a container is very bleading edge. I would not be
> surprised at all if you run into lots of problems.
> 
> On Tue, 2015-09-22 at 12:10 -0600, Duncan McNaught wrote:
>> Thanks Nathaniel,
>>   I am running with Jan's Centos-7 container and I'd like to have
>> Multi-factor Authentication/2FA enabled.
>> He mentioned that systemd is not running in the container, so I
>> guess that explains why 2FA is failing. I wonder if I can get
>> systemd running there.
>> --Duncan
>>
>>
>> Thanks
>> --Duncan
>> 
>> Duncan McNaught
>> Infrastructure Engineer
>>  Technologies | www.bitnet.io
>> +1 720 240 6575
>>
>> On Tue, Sep 22, 2015 at 6:55 AM, Nathaniel McCallum > t.com> wrote:
>>> On Mon, 2015-09-21 at 16:49 -0600, Duncan McNaught wrote:
 Dear freeipa-users,

 I'm having an issue with otp in freeipa. I can set up the
>>> service as
 described in the blog post for TOTP or HOTP, and sync the token
>>> fine.
 When I try to login to the admin tools or an ipa-managed client
 (with ) , I get a password incorrect message.
 Here are some more details: https://github.com/adelton/docker-fre
>>> eipa
 /issues/34
 Can anyone help me to debug/get this working?
>>>
>>> I'm very unclear as to what you are trying to do. Are you trying to
>>> run FreeIPA in a container? If so, Jan is probably your man. AFAIK,
>>> ipa-otpd will require systemd in the container.
>>>
>>> If you are trying to run this on CentOS 7.1 (not a container), it
>>> seems to me that your LDAP server isn't running or something is
>>> wrong
>>> with ldapi.
>>>
>>> Can you explain your setup in more detail?
>>>
>>> Nathaniel
>>>
> 

-- 
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] [Import existing CA Cert]

[Martin Kosek]

On 09/23/2015 10:05 AM, Michael Anderson wrote:
> Hi Martin,
> 
> thanks for your reply.
> 
> On 09/23/2015 09:07 AM, Martin Kosek wrote:
>> On 09/22/2015 12:41 PM, Michael Anderson wrote:
>>>   Hi All,
>>>
>>> we're evaluation freeipa/dogtag as a pki management service and hoping to
>>> replace our existing menagerie of bash/openssl scripts. I'm trying to 
>>> establish
>>> a migration path for our existing pki solution and have a few questions:
>> Hi Michael,
>>
>> Before you continue with the project, please keep in mind that FreeIPA PKI
>> capabilities are bound to the FreeIPA objects - i.e. users, hosts or 
>> services.
>> It does not allow you to generate completely random certificates (at the
>> moment).
> 
> Does that mean that I can only generate certificates for hosts running the
> client software?

Well, you need at least the host object in FreeIPA, to be able to generate
certificate for it. It does not need to be effectively used.

> What I'd really like to be able to do is automate Apache/Nginx
> SSL cert generation for our dev/continuous-delivery infrastructure. So I'd 
> like
> to have two or three signing CA's for dev, staging and prod and automate CSR
> creation, signing and deployment. Is this feasible with freeipa?

So the requirement here is to have different Sub-CA for these environments?
FreeIPA 4.2 cannot do Sub-CAs yet, this is work proposed for next release:

https://fedorahosted.org/freeipa/ticket/4559

BTW, this is how you can request renewable certificates for HTTP with FreeIPA:

http://www.freeipa.org/page/PKI#Automated_certificate_requests_with_Certmonger

>>> '* how can I import and use our existing CA signing cert?
>>> * can I import existing server certs and keys?
>> Could you create FreeIPA server CA as subordinate CA to your current CA? To 
>> me,
>> it seems the easiest way as I do not think we have some nice CLIs to inject
>> existing CA cert+key to FreeIPA/Dogtag. CCing Jan and Fraser to see if they
>> have an idea.
>>
>> More here:
>> http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructurell
> 
> With my current project I'll be rebuilding a lot of stuff, so starting fresh
> with a new freeipa-generated signing cert won't be such a problem. That said,
> it seems to me that the ability to import and use an existing signing cert
> would lower the adoption threshold for new users.

My point was that if FreeIPA is a subordinate CA, it should be still trusted by
your clients that would have already imported it's CA certificate.

>>> * I'm using Fedora22. When I install dogtag-pki, the user page for 
>>> submitting
>>> csr's is available. But when I install the freeipa package, I get a 404 when
>>> attempting to access the page. Is this functionality available in freeipa?
>> When PKI is configured as part of FreeIPA, FreeIPA takes control of 
>> requesting
>> and passing the certificates from/to user. I think the Dogtag UI should be
>> still somehow accessible, but is not the supported way.
>>
>> FreeIPA itself can accept CSRs via cert-request CLI command or Web UI page, 
>> or
>> via certmonger (man ipa-getcert) component that even renews the certificate.
>>
>> BTW, what version of FreeIPA are you using? FreeIPA 4.2 provides much more 
>> PKI
>> related capabilities than older versions, for beginning Certificate Profiles,
>> which are a must if you do not want to use just single fixed cert profile.
> 
> I'm using the version packaged with Fedora 22, 4.1.4

Ok. If you want to try the new FreeIPA 4.2 with Certificate Profiles on Fedora
22,  there should be a COPR repo also:

https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/

>> More here:
>> http://www.freeipa.org/page/Releases/4.2.0
>>
>> 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

[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

Re: [Freeipa-users] Ghost user?

[Janelle]

On 9/23/15 10:36 AM, Martin Basti wrote:



On 09/23/2015 07:15 PM, Janelle wrote:
I have a user I created for testing, but now shows as both "there" 
but not there..


*ipa user-show jtest*

 ipa: ERROR: jtest: user not found

*ipa user-find jtest*
--
1 user matched
--
  User login: jtest
  First name: janelle
  Last name: test
  Home directory: /home/jtest
  Login shell: /bin/bash
  Email address: jt...@example.com
  UID: 1372025403
  GID: 1372025403
  Account disabled: False
  Password: True
  Kerberos keys available: True

*ipa user-del jtest*
 ipa: ERROR: jtest: user not found

*ipa user-add jtest*
First name: janelle
Last name: jtest
ipa: ERROR: user with name "jtest" already exists


I am officially baffled. Any ideas?
~Janelle





Hello,

can you please check directly with LDAP search, if it is replication 
conflict?


Martin
I am not sure what I am looking for to determine the replication 
conflict you speak of. I know how to use ldapsearch, but not sure what 
you want to see.


~J

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

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

[Michael Lasevich]

I actually just posted that in a previous email. The only thing I cut out
were nsSSLEnabledCiphers - but here is the complete listing:

#  ldapsearch -x -D "cn=directory manager" -W -b "cn=encryption,cn=config"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] dns_lookup_kdc question

[Aly Khimji]

Excellent,

Thank you for the quick response.
I will look further into your suggestions

Aly


On Wed, Sep 23, 2015 at 3:50 PM, Alexander Bokovoy 
wrote:

> On Wed, 23 Sep 2015, Aly Khimji wrote:
>
>> Hey guys,
>>
>> Quick question. Just running through a poc and ran into a question.
>>
>> I have a simple AD DC (win2k8r2 box) with a trust setup to our IPA server.
>> Trust and all is setup properly and I can see users on the client/ipa
>> server and on the ipa server I can ssh into it with the AD user.
>>
>> I am finding that users are unable to log into the "client nodes" and are
>> getting a "4: System Error" failure in the ssh log. When I dig into the
>> sssd in debug mode I can see its failing to find KDC for the "realm".
>> Makes
>> sense so far. So I enable dns_lookup_kdc = true and now it is able to find
>> the realm and login is successful.
>>
> Correct.
>
>
> My question is, this "dns_lookup_kdc = true" required in any setup with
>> AD/IPA trust + ssh into IPA client with AD users?
>>
> Yes, in currently released versions you have to have that in the
> krb5.conf.
>
> I am wondering as there may be a use case where the AD server is in another
>> network and IPA clients won't have direct access to AD. I was wondering if
>> there is any model in which the client only ever talks to IPA server and
>> all the AD/Kerbos communication is handled via the IPA server and if so
>> how
>> is this done?
>>
> Yes, there is a way to do so with FreeIPA 4.2, by using KDC proxy
> functionality.
>
> You can enable KDC proxy on IPA master and make sure to set manually on
> each client a 'kdc' property for each AD realm to point to
> https://ipa.master/KDCProxy. Then on the IPA master itself have explicit
> define in krb5.conf for AD realms pointing to proper AD DCs for 'kdc'
> property.
> With this setup you would have all Kerberos traffic (same can be done
> with kadmin protocol too, I think) redirected via IPA masters to AD DCs.
>
> You need to have fairly recent MIT Kerberos library for that, though.
> RHEL7 should be OK. I haven't checked latest MIT krb5 backports in
> RHEL6, though.
>
> I have read a bit and this looks as though what I am doing here is a
>> "legacy" setup. Just wondering if this is different in sssd 1.9 or if kdc
>> =
>> True is always required.
>>
>> I am not doing anything extra on the client other then the ipa-client
>> install.
>> No manual adjustment of sssd.conf or krb5.conf. If I am missing something
>> please advise.
>>
> ipa-client-install sets 'dns_lookup_kdc = true' by default if your DNS
> discovery of KDC was successful and no '--force' option was specified.
>
>
> --
> / 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] sudo not work in linux

[Jakub Hrozek]

On Wed, Sep 23, 2015 at 12:48:47PM +0330, alireza baghery wrote:
> hi
> i have centos 6.7 (ipa server)
> and i have centos 6.5 (client)

I would advise to upgrade, 6.5 is old. I'm not sure if 6.5 already
supported sudo_provider=ipa, but I'm pretty sure 6.6 did. That would
simplify the configuration a lot.

> i can not sudo on client
> i add rule sudo on ipa
> i config file sss.conf

Are there any rules in the cache (ldbsearch -H
/var/lib/sss/db/cache_l.infotechpsp.net) at all?

If not, then I guess the rules don't match the host, because your domain
log snippet indicates sssd couldn't fetch the rules..

> +++
> 
> [domain/l.infotechpsp.net]
> debug_level = 6
> #cache_credentials = True
> #krb5_store_password_if_offline = True
> ipa_domain = l.infotechpsp.net
> id_provider = ipa
> #auth_provider = ipa
> #access_provider = ipa
> #ipa_hostname = switchlive.l.infotechpsp.net
> #chpass_provider = ipa
> ipa_server = _srv_, ipasrv.l.infotechpsp.net
> ldap_tls_cacert = /etc/ipa/ca.crt
> sudo_provider = ldap
> ldap_uri =ldap://ipasrv.l.infotechpsp.net
> ldap_sudo_search_base = ou=sudoers,dc=l,dc=infotechpsp,dc=net
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid = host/ussd7rep.l.infotechpsp.net
> ldap_sasl_realm = L.INFOTECHPSP.NET
> krb5_server = ipasrv.l.infotechpsp.net
> [sssd]
> config_file_version = 2
> 
> # Number of times services should attempt to reconnect in the
> # event of a crash or restart before they give up
> reconnection_retries = 3
> 
> # If a back end is particularly slow you can raise this timeout here
> sbus_timeout = 30
> services = nss, pam, ssh, sudo
> 
> domains = l.infotechpsp.net
> [nss]
> 
> 
> [pam]
> +++
> in file nsswitch.conf
> add sudoers: files sss
> 
> and log file /var/log/sss/sss_l.
> +
> 
> (Wed Sep 23 12:28:52 2015) [sssd[be[l.infotechpsp.net]]]
> [be_resolve_server_process] (0x0200): Found address for server
> ipasrv.l.infotechpsp.net: [10.30.160.19] TTL 1200
> (Wed Sep 23 12:28:52 2015) [sssd[be[l.infotechpsp.net]]]
> [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child
> (Wed Sep 23 12:28:52 2015) [sssd[be[l.infotechpsp.net]]]
> [write_pipe_handler] (0x0400): All data has been sent!
> (Wed Sep 23 12:28:52 2015) [sssd[be[l.infotechpsp.net]]]
> [read_pipe_handler] (0x0400): EOF received, client finished
> (Wed Sep 23 12:28:52 2015) [sssd[be[l.infotechpsp.net]]]
> [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/
> ccache_L.INFOTECHPSP.NET], expired on [1443085132]
> (Wed Sep 23 12:28:52 2015) [sssd[be[l.infotechpsp.net]]]
> [sdap_cli_auth_step] (0x0100): expire timeout is 900
> (Wed Sep 23 12:28:52 2015) [sssd[be[l.infotechpsp.net]]] [sasl_bind_send]
> (0x0100): Executing sasl bind mech: GSSAPI, user: host/
> ussd7rep.l.infotechpsp.net
> (Wed Sep 23 12:28:53 2015) [sssd[be[l.infotechpsp.net]]]
> [child_sig_handler] (0x0100): child [12755] finished successfully.
> (Wed Sep 23 12:28:53 2015) [sssd[be[l.infotechpsp.net]]]
> [fo_set_port_status] (0x0100): Marking port 389 of server '
> ipasrv.l.infotechpsp.net' as 'working'
> (Wed Sep 23 12:28:53 2015) [sssd[be[l.infotechpsp.net]]]
> [set_server_common_status] (0x0100): Marking server '
> ipasrv.l.infotechpsp.net' as 'working'
> (Wed Sep 23 12:28:53 2015) [sssd[be[l.infotechpsp.net]]]
> [sdap_sudo_refresh_connect_done] (0x0400): SUDO LDAP connection successful
> (Wed Sep 23 12:28:53 2015) [sssd[be[l.infotechpsp.net]]]
> [sdap_sudo_load_sudoers_next_base] (0x0400): Searching for sudo rules with
> base [ou=sudoers,dc=l,dc=infotechpsp,dc=net]
> (Wed Sep 23 12:28:53 2015) [sssd[be[l.infotechpsp.net]]]
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> [(&(&(objectclass=sudoRole)(entryUSN>=128274)(!(entryUSN=128274)))(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=
> ussd7rep.l.infotechpsp.net
> )(sudoHost=ussd7rep)(sudoHost=10.30.110.11)(sudoHost=
> 10.30.110.0/24)(sudoHost=fe80::250:56ff:feaf:3ca6)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*][ou=sudoers,dc=l,dc=infotechpsp,dc=net
> ].
> (Wed Sep 23 12:28:53 2015) [sssd[be[l.infotechpsp.net]]]
> [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
> set
> (Wed Sep 23 12:28:53 2015) [sssd[be[l.infotechpsp.net]]]
> [sdap_sudo_load_sudoers_process] (0x0400): Receiving sudo rules with base
> [ou=sudoers,dc=l,dc=infotechpsp,dc=net]
> (Wed Sep 23 12:28:53 2015) [sssd[be[l.infotechpsp.net]]]
> [sdap_sudo_load_sudoers_done] (0x0400): Received 0 rules
> (Wed Sep 23 12:28:53 2015) [sssd[be[l.infotechpsp.net]]]
> [sdap_sudo_load_sudoers_done] (0x0400): Sudoers is successfuly stored in
> cache
> (Wed Sep 23 12:28:53 2015) [sssd[be[l.infotechpsp.net]]]
> [sdap_sudo_smart_refresh_done] (0x0400): Successful smart refresh of sudo
> rules
> +

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

Re: [Freeipa-users] sssd public socket error

[Jakub Hrozek]

On Wed, Sep 23, 2015 at 06:03:45PM +, Andy Thompson wrote:
> On one of my servers I'm getting
> 
> Sep 23 13:35:07 mdhixuatisamw03 sshd[8136]: pam_unix(sshd:session): session 
> opened for user user by (uid=0)
> Sep 23 13:35:07 mdhixuatisamw03 sshd[8164]: pam_sss(sshd:setcred): Request to 
> sssd failed. Public socket has wrong ownership or permissions.
> 
> Authentication still works but group name lookups fail on the server.
> 
> Haven't been able to track down yet what config is different on this server 
> and I can't find any information on this, anyone have any thoughts?

The code is:
860 statret = stat(SSS_PAM_SOCKET_NAME, _buf);
861 if (statret != 0) {
862 ret = PAM_SERVICE_ERR;
863 goto out;
864 }
865 if ( ! (stat_buf.st_uid == 0 &&
866 stat_buf.st_gid == 0 &&
867 S_ISSOCK(stat_buf.st_mode) &&
868 (stat_buf.st_mode & ~S_IFMT) == 0666 )) {
869 *errnop = ESSS_BAD_PUB_SOCKET;
870 ret = PAM_SERVICE_ERR;
871 goto out;
872 }
873

I would compare:
ls -lR /var/lib/sss/pipes/

on a working or a non-working server. The public PAM socket
(/var/lib/sss/pipes/pam) should be there and should have permission 0666.

Also check AVC denials.

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

[Alexander Bokovoy]

On Wed, 23 Sep 2015, Aly Khimji wrote:

Hey guys,

Quick question. Just running through a poc and ran into a question.

I have a simple AD DC (win2k8r2 box) with a trust setup to our IPA server.
Trust and all is setup properly and I can see users on the client/ipa
server and on the ipa server I can ssh into it with the AD user.

I am finding that users are unable to log into the "client nodes" and are
getting a "4: System Error" failure in the ssh log. When I dig into the
sssd in debug mode I can see its failing to find KDC for the "realm". Makes
sense so far. So I enable dns_lookup_kdc = true and now it is able to find
the realm and login is successful.

Correct.



My question is, this "dns_lookup_kdc = true" required in any setup with
AD/IPA trust + ssh into IPA client with AD users?

Yes, in currently released versions you have to have that in the
krb5.conf.


I am wondering as there may be a use case where the AD server is in another
network and IPA clients won't have direct access to AD. I was wondering if
there is any model in which the client only ever talks to IPA server and
all the AD/Kerbos communication is handled via the IPA server and if so how
is this done?

Yes, there is a way to do so with FreeIPA 4.2, by using KDC proxy
functionality.

You can enable KDC proxy on IPA master and make sure to set manually on
each client a 'kdc' property for each AD realm to point to
https://ipa.master/KDCProxy. Then on the IPA master itself have explicit
define in krb5.conf for AD realms pointing to proper AD DCs for 'kdc'
property. 


With this setup you would have all Kerberos traffic (same can be done
with kadmin protocol too, I think) redirected via IPA masters to AD DCs.

You need to have fairly recent MIT Kerberos library for that, though.
RHEL7 should be OK. I haven't checked latest MIT krb5 backports in
RHEL6, though.


I have read a bit and this looks as though what I am doing here is a
"legacy" setup. Just wondering if this is different in sssd 1.9 or if kdc =
True is always required.

I am not doing anything extra on the client other then the ipa-client
install.
No manual adjustment of sssd.conf or krb5.conf. If I am missing something
please advise.

ipa-client-install sets 'dns_lookup_kdc = true' by default if your DNS
discovery of KDC was successful and no '--force' option was specified.


--
/ 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] V6 and v4

[Janelle]

On 9/13/15 11:46 PM, Alexander Bokovoy wrote:

On Sun, 13 Sep 2015, Janelle wrote:

Hello,

I read something recently that if ip v6 is disable on a server this
hurts performance in some way? Is there more info on this or did I
misread it?

Do not disable IPv6 stack on your machines. By disabling IPv6 you are
not doing good. On contrary, many contemporary software projects are
using IPv6-enabled network calls by default because both IPv6 and IPv4
share the same name space on the machine so you only need to listen on a
IPv6 port to accept both IPv4 and IPv6. This is a recommended approach
for networking applications' developers for years already.

Note that this means only that support for IPv6 stack is enabled in the
kernel. You are not required to go with IPv6 networking addresses, this
is not really needed if you don't want to. But allowing applications to
be IPv6 aware is required.

FreeIPA has several components which are programmed in such way that
they expect IPv6 stack to be enabled for reasons outlined above. If you
disable IPv6 stack, FreeIPA will partially malfunction and will not
really be in a supported state, especially when we are talking about
trusts to Active Directory (and, in future, IPA to IPA trust).

BTW - I did re-enable IPv6 and was able to "clean ruv" all the "dead" 
entries, which I had not been able to do before. Thank you for this.


~J

--
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] Ubuntu Samba Server Auth against IPA

[Matt .]

Hi Guys,

Please keep this topic updated as many people seem to have this question.

What's the status at your side ?

Cheers,

Matt

2015-09-04 15:27 GMT+02:00 Matt . :
> Hi,
>
> Does everyone have this working or gived up on it ?
>
> Chers,
>
> Matt
>
> 2015-08-26 20:07 GMT+02:00 Matt . :
>> Chris,
>>
>> How far are you on this ? I'm stuck atm :(
>>
>> I hope you have some reference notes to follow and check out.
>>
>> Thanks!
>>
>> Matt
>>
>> 2015-08-20 22:15 GMT+02:00 Matt . :
>>> Hi Chris,
>>>
>>> Would be great to see!
>>>
>>> If I have it working and we have 2-3 testcases I think we can add it
>>> to the IPA docs!
>>>
>>> Keep me updated!
>>>
>>> Thanks
>>>
>>> Matt
>>>
>>> 2015-08-20 8:49 GMT+02:00 Christopher Lamb :
 Matt

 Once I got Samba and FreeIPA integrated (by the "good old extensions"
 path), I always use FreeIPA to administer users. I have never tried the
 samba tools like smbpasswd.

 I still have a wiki how-to in the works, but I had to focus on some other
 issues for a while.

 Chris



 From:   "Matt ." 
 To: Youenn PIOLET 
 Cc: Christopher Lamb/Switzerland/IBM@IBMCH,
 "freeipa-users@redhat.com" 
 Date:   20.08.2015 08:12
 Subject:Re: [Freeipa-users] Ubuntu Samba Server Auth against IPA



 HI Guys,

 Anyone still a working clue/test here ?

 I didn't came further as it seems there need to be some domain join /
 match following the freeipa devs.

 Thanks!

 Matt

 2015-08-13 13:09 GMT+02:00 Matt . :
> Hi,
>
> I might have found somthing which I already seen in the logs.
>
> I did a smbpasswd my username on the samba server, it connects to ldap
> very well. I give my new password and get the following:
>
> smbldap_search_ext: base => [dc=my,dc=domain], filter =>
> [(&(objectClass=ipaNTGroupAttrs)(|
 (ipaNTSecurityIdentifier=S-1my--sid---)))],
> scope => [2]
> Attribute [displayName] not found.
> Could not retrieve 'displayName' attribute from cn=Default SMB
> Group,cn=groups,cn=accounts,dc=my,dc=domain
> Sid S-1my--sid--- -> MYDOMAIN\Default SMB Group(2)
>
> So something is missing!
>
> Thanks so far guys!
>
> Cheers,
>
> Matt
>
> 2015-08-13 12:02 GMT+02:00 Matt . :
>> Hi Youenn,
>>
>> OK thanks! this takes me a little but futher now and I see some good
>> stuff in my logging.
>>
>> I'm testing on a Windows 10 Machine which is not member of an AD or
>> so, so that might be my issue for now ?
>>
>> When testing on the samba box itself as my user I get:
>>
>>
>> [myusername@smb-01 ~]$ smbclient //smb-01.domain.local/shares
>>
>> ...
>> Checking NTLMSSP password for MSP\myusername failed:
 NT_STATUS_WRONG_PASSWORD
>> ...
>> SPNEGO login failed: NT_STATUS_WRONG_PASSWORD
>>
>>
>> Maybe I have an issue with encrypted passwords ?
>>
>>
>> When we have this all working, I think we have a howto :D
>>
>> Thanks!
>>
>> Matt
>>
>> 2015-08-13 10:53 GMT+02:00 Youenn PIOLET :
>>> Hi Matt
>>>
>>> - CentOS : Did you copy ipasam.so and change your smb.conf accordingly?
>>> sambaSamAccount is not needed anymore that way.
>>> - Default IPA Way : won't work if your Windows is not part of a domain
>>> controller. DOMAIN\username may work for some users using Windows 7 -
 not 8
>>> nor 10 (it did for me but I was the only one at the office... quite
 useless)
>>>
>>> This config may work on your CentOS (for the ipasam way):
>>> workgroup = TEST
>>> realm = TEST.NET
>>> kerberos method = dedicated keytab
>>> dedicated keytab file = FILE:/<.>/samba.keytab
>>> create krb5 conf = no
>>> security = user
>>> encrypt passwords = true
>>> passdb backend = ipasam:ldaps://youripa.test.net
>>> ldapsam:trusted = yes
>>> ldapsuffix = test.net
>>> ldap user suffix = cn=users,cn=accounts
>>> ldap group suffix = cn=groups,cn=accounts
>>>
>>>
>>> --
>>> Youenn Piolet
>>> piole...@gmail.com
>>>
>>>
>>> 2015-08-12 22:15 GMT+02:00 Matt . :

 Hi,

 OK the default IPA way works great actually when testing it as
 described
 here:


 http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA

 On the samba server I can auth and see my share where I want to
 connect
 to.

 The issue is, on Windows I cannot auth, even when I do DOMAIN\username

[Freeipa-users] Generic preauthentication failure while getting initial credentials using kinit -k -t

[Brian J. Murrell]

I've put a kerberos principle into a keytab:

# klist -k asterisk.keytab
Keytab name: FILE:asterisk.keytab
KVNO Principal
 --
   8 aster...@example.com

using:

# ipa-getkeytab -s server.example.com -p asterisk -k /tmp/asterisk-krb5.keytab 
-e aes256-cts

But when I try to use that keytab I get an error:

# kinit -k -t /etc/asterisk/asterisk.keytab imap/linux.example@example.com
kinit: Generic preauthentication failure while getting initial credentials

On the server I get the following error:

Sep 23 19:30:39 server.example.com krb5kdc[28970](info): AS_REQ (7 etypes {18 
17 16 23 1 3 2}) xx: NEEDED_PREAUTH: imap/linux.example@example.com for 
krbtgt/example@example.com, Additional pre-authentication required

Any idea what is going on here?

Cheers,
b.


signature.asc
Description: This is a digitally signed message part
-- 
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] Automatic IPA CA cert generation

[Fraser Tweedale]

On Wed, Sep 23, 2015 at 11:16:27AM +0100, James Masson wrote:
> 
> On 23/09/15 11:03, Fraser Tweedale wrote:
> >On Wed, Sep 23, 2015 at 09:09:25AM +0200, David Kupka wrote:
> >>On 22/09/15 17:02, James Masson wrote:
> >>>
> >>>Hi,
> >>>
> >>>we're building IPAs in an automated fashion, for environments that get
> >>>created and destroyed a lot. At the moment, the CA certs used inside
> >>>these IPAs are self-signed, as part of the normal "ipa-server-install"
> >>>setup process.
> >>>
> >>>We would like to switch to issuing signed intermediate CA certs to the
> >>>IPAs we deploy.
> >>>
> >>>The documentation lists the two part process necessary for this. First
> >>>"--external-ca" - and then "--external-cert-file"
> >>>
> >>>Are there any ways to skip this, and give the setup process a known
> >>>public/private key+cert up front? I'm hoping to avoid the need to have
> >>>to use/send this automatically generated CSR every time.
> >>>
> >>>thanks
> >>>
> >>>James M
> >>>
> >>
> >>Hello James,
> >>currently it's not possible but making installation with externally signed
> >>CA single step sounds really useful to me.
> >>Currently certmonger is generating the CSR for FreeIPA server in the first
> >>step of installation. Certmonger is also able to send certificate to
> >>external CA for signing.
> >>
> >>I'm not sure if we could combine these two cermonger's abilities right now
> >>but if not it shouldn't be difficult to add functionality to certmonger to
> >>send the CSR to preconfigured CA instead of just storing it in file.
> >>
> >>This would of course require configuring the certmonger with information
> >>about the CA before FreeIPA server installation but it's just one command
> >>(getcert-add-ca).
> >>
> >>Could you please file a ticket (https://fedorahosted.org/freeipa/newticket)?
> >>
> >There are two sides to this - one is using Certmonger for automatic
> >signing of intermediate CA certificate to be used by IPA, the other
> >is simply using a CA cert that the administrator already possesses,
> >e.g. in a PKCS #12 file.  These should be separate tickets.
> >
> >Cheers,
> >Fraser
> >
> >>--
> >>David Kupka
> >>
> >>--
> >>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
> 
> Done -
> 
> https://fedorahosted.org/freeipa/ticket/5317
> https://fedorahosted.org/freeipa/ticket/5318
> 
> Would it be possible to use Certmonger to help the 2 step process used at
> the moment?
> 
> ie. run 'ipa-server-install' the first time - get the CSR
> use local Certmonger to handle the CSR submission to upstream CA
> use the resulting Cert in the second 'ipa-server-install'
> 
> Any pointers?
> 
> regards
> 
> James M
> 
I don't see an option for certmonger to use an existing CSR but you
could ask it to create and track a new CSR for the same key.  See
getcert-request(1) for full details.

Cheers,
Fraser

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

[Andy Thompson]

I've got all of my environments setup with two IPA servers.  I'm fighting 
intermittent problems with krb5kdc crashing on them in all of my environments 
and I've opened a ticket with Redhat on that.  What I can't figure out though 
is why the clients will not fail over to the second functioning server in the 
domain

My sssd.conf files are all pretty generic from the install with minimal 
modification to add a couple settings.

[domain/mhbe.lin]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = mhbe.lin
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = mdhixproddb01.mhbe.lin
chpass_provider = ipa
ipa_server = _srv_, mdhixprodipa01.mhbe.lin
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
default_domain_suffix = mhbe.local
services = nss, sudo, pam, ssh
config_file_version = 2

domains = mhbe.lin
[nss]
default_shell = /bin/bash
homedir_substring = /home
debug_level = 7
[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

I thought the _srv_  would force it to use dns and both servers are round 
robined when digging the _kerberos records from DNS.  So I don't understand why 
it's not working


Thanks

-andy



*** This communication may contain privileged and/or confidential information. 
It is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. ***


-- 
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] IPA server failover

[Alexander Bokovoy]

On Wed, 23 Sep 2015, Andy Thompson wrote:

I've got all of my environments setup with two IPA servers.  I'm
fighting intermittent problems with krb5kdc crashing on them in all of
my environments and I've opened a ticket with Redhat on that.  What I
can't figure out though is why the clients will not fail over to the
second functioning server in the domain

My sssd.conf files are all pretty generic from the install with minimal
modification to add a couple settings.

[domain/mhbe.lin]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = mhbe.lin
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = mdhixproddb01.mhbe.lin
chpass_provider = ipa
ipa_server = _srv_, mdhixprodipa01.mhbe.lin
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
default_domain_suffix = mhbe.local
services = nss, sudo, pam, ssh
config_file_version = 2

domains = mhbe.lin
[nss]
default_shell = /bin/bash
homedir_substring = /home
debug_level = 7
[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

I thought the _srv_  would force it to use dns and both servers are
round robined when digging the _kerberos records from DNS.  So I don't
understand why it's not working

ipa_server is for SSSD tasks using LDAP server. Kerberos libraries are
using /etc/krb5.conf for hints where to find KDCs.

A combination of 'dns_lookup_kdc = true' in [libdefaults] and missing
'kdc = ' for specific realm would cause Kerberos clients to do DNS
discovery using SRV records.

If multiple 'kdc = ...' values are specified in the realm definition,
Kerberos clients will fall over to the next one in the list in case of a
failure. 


When ipa-client-install is run, we configure krb5.conf without explicit
KDCs if DNS discovery of Kerberos was successful which should take care
of SRV record-based discovery of KDCs.
--
/ 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] Generic preauthentication failure while getting initial credentials using kinit -k -t

[Alexander Bokovoy]

On Wed, 23 Sep 2015, Brian J. Murrell wrote:

I've put a kerberos principle into a keytab:

# klist -k asterisk.keytab
Keytab name: FILE:asterisk.keytab
KVNO Principal
 --
  8 aster...@example.com

using:

# ipa-getkeytab -s server.example.com -p asterisk -k /tmp/asterisk-krb5.keytab 
-e aes256-cts

But when I try to use that keytab I get an error:

# kinit -k -t /etc/asterisk/asterisk.keytab imap/linux.example@example.com
kinit: Generic preauthentication failure while getting initial credentials

On the server I get the following error:

Sep 23 19:30:39 server.example.com krb5kdc[28970](info): AS_REQ (7
etypes {18 17 16 23 1 3 2}) xx: NEEDED_PREAUTH:
imap/linux.example@example.com for krbtgt/example@example.com,
Additional pre-authentication required

Any idea what is going on here?

You need to explain what are you trying to achieve first.

The sequence above:

- Sets a random Kerberos key for a principal named aster...@example.com
  on IPA KDC and stores it to the local keytab file asterisk.keytab
- tries to use a key for aster...@example.com to obtain ticket granting
  ticket as imap/linux.example@exampe.com

Unless imap/linux.example@example.com has exactly same Kerberos key
as aster...@example.com, the above should fail and it does.

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