Re: [Freeipa-users] Crazy Cert problem?

2015-06-23 Thread Janelle

On 6/22/15 7:37 AM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 2:00 PM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 6:21 AM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 6:14 AM, Rob Crittenden wrote:

Janelle wrote:

Hi,

Had a server - named ipa001.example.com -- it was a replica. It
died. It
was re-installed. However, prior to the re-install it was 
saying the

wonderful:

TLS error -8172:Peer's certificate issuer has been marked as not
trusted
by the user.

It was rebuilt - new OS and doing a brand new ipa-server-install
(NOT a
replica or trying to join it back in to the existing ring of
servers)
and at the end of the ipa-server-install - it gives:

Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Restarting the web server
Unable to set admin password Command ''/usr/bin/ldappasswd' '-h'
'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y'
'/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs'
'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned
non-zero
exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command 
''/usr/sbin/ipa-client-install'

'--on-master' '--unattended' '--domain' 'example.com' '--server'
'ipa001.example.com' '--realm' 'example.com' '--hostname'
'ipa001.example.com'' returned non-zero exit status 1

and checking /var/log/ipaclient-install.log - the exact same TLS
error

But this is a brand new system, with brand new OS and the install
was
ipa-server-install to install a clean server.

I don't understand how this is happening. There is no peer to
be not
trusted?


What version of IPA and distro? (I don't think that probably has
anything to do with it, just curious in case it does eventually
matter).

What does /etc/openldap/ldap.conf look like? Normally it should 
have

TLS_CACERT /etc/ipa/ca.crt

Any chance you can share the server and client install logs?

rob

4.1.4 = IPA
CentOS 7.1

Oooh... Found something:  /etc/openldap/ldap.conf:

TLS_CACERTDIR/etc/openldap/certs

Going to investigate.
~J



That should be fine assuming there aren't any certs in there (and 
on a

brand new system I'd think you'd have empty NSS databases).

rob

So this gets interesting now...

Say you have 6 IPA servers, named ipa001-ipa006.example.com -- all
working fine.
Something happens to 002. It dies. You ipa-replica-manage del --clean
--force ipa002 to get rid of it.

A period of time, say a month, goes by. You have lost a couple of 
other

replicas for whatever reason, say 3 and 6. You decide you want to
rebuild. You start with 002 - leaving the others up and running 
because

you have users working. You firewall off 002 why you rebuild it.

You reinstall OS, reinstall FreeIPA. But no matter what, when you 
start
to configure IPA it comes up with the error of being untrusted. 
Now, you

try the same thing on 003 and 006. SAME problem.

For fun - you shutdown 005 and uninstall freeipa --unattended and then
try to re-install it. Guess what - no issues.

Is this somehow related to:
Same domain and realm names floating around the net - so is it 
querying

for a name somehow and one of the still running servers is saying -
NO NO NO -- that CERT is revoked!!! - even though it never tries to
connect to that server.

Or am I just thinking far too outside the box?  And this is exactly 
what

has happened. Rebuilding one of the servers that was never REMOVED is
working just fine.


You just jumped to a completely different scenario: from a fresh
standalone install to a replica install. We should probably pick one
and solve it.

I think the leap you're making is that the issue is that it notices
some previous cert. A revoked service cert wouldn't have any effect as
those service certs aren't in use.

It very well could be finding the wrong realm based on DNS SRV
records. The logs should show you what the client discovered. Things
happen in multiple steps so perhaps there is a disconnect where the
right server is used in some, but not all, cases.

rob


ALL the problems were all related. Even after building brand new
servers, the problem persisted and then started cropping up with client
installs.

The solution traced to bad NSS packages. A simple yum downgrade nss
nss-sysinit nss-tools solved it.. Something is up with the 3.18 verion
and downgrading to 3.16 seems to have resolved. Should have known it
would all be related to an upgrade.  Sometimes a slightly older version
is best.

~Janelle


Can you open a bugzilla about this?

rob

This looks like the fix - besides downgrading:

https://bugzilla.mozilla.org/show_bug.cgi?id=1132941


--
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] Crazy Cert problem?

2015-06-22 Thread Rob Crittenden

Janelle wrote:

On 6/17/15 2:00 PM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 6:21 AM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 6:14 AM, Rob Crittenden wrote:

Janelle wrote:

Hi,

Had a server - named ipa001.example.com -- it was a replica. It
died. It
was re-installed. However, prior to the re-install it was saying the
wonderful:

TLS error -8172:Peer's certificate issuer has been marked as not
trusted
by the user.

It was rebuilt - new OS and doing a brand new ipa-server-install
(NOT a
replica or trying to join it back in to the existing ring of
servers)
and at the end of the ipa-server-install - it gives:

Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Restarting the web server
Unable to set admin password Command ''/usr/bin/ldappasswd' '-h'
'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y'
'/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs'
'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned
non-zero
exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
'--on-master' '--unattended' '--domain' 'example.com' '--server'
'ipa001.example.com' '--realm' 'example.com' '--hostname'
'ipa001.example.com'' returned non-zero exit status 1

and checking /var/log/ipaclient-install.log - the exact same TLS
error

But this is a brand new system, with brand new OS and the install
was
ipa-server-install to install a clean server.

I don't understand how this is happening. There is no peer to
be not
trusted?


What version of IPA and distro? (I don't think that probably has
anything to do with it, just curious in case it does eventually
matter).

What does /etc/openldap/ldap.conf look like? Normally it should have
TLS_CACERT /etc/ipa/ca.crt

Any chance you can share the server and client install logs?

rob

4.1.4 = IPA
CentOS 7.1

Oooh... Found something:  /etc/openldap/ldap.conf:

TLS_CACERTDIR/etc/openldap/certs

Going to investigate.
~J



That should be fine assuming there aren't any certs in there (and on a
brand new system I'd think you'd have empty NSS databases).

rob

So this gets interesting now...

Say you have 6 IPA servers, named ipa001-ipa006.example.com -- all
working fine.
Something happens to 002. It dies. You ipa-replica-manage del --clean
--force ipa002 to get rid of it.

A period of time, say a month, goes by. You have lost a couple of other
replicas for whatever reason, say 3 and 6. You decide you want to
rebuild. You start with 002 - leaving the others up and running because
you have users working. You firewall off 002 why you rebuild it.

You reinstall OS, reinstall FreeIPA. But no matter what, when you start
to configure IPA it comes up with the error of being untrusted. Now, you
try the same thing on 003 and 006. SAME problem.

For fun - you shutdown 005 and uninstall freeipa --unattended and then
try to re-install it. Guess what - no issues.

Is this somehow related to:
Same domain and realm names floating around the net - so is it querying
for a name somehow and one of the still running servers is saying -
NO NO NO -- that CERT is revoked!!! - even though it never tries to
connect to that server.

Or am I just thinking far too outside the box?  And this is exactly what
has happened. Rebuilding one of the servers that was never REMOVED is
working just fine.


You just jumped to a completely different scenario: from a fresh
standalone install to a replica install. We should probably pick one
and solve it.

I think the leap you're making is that the issue is that it notices
some previous cert. A revoked service cert wouldn't have any effect as
those service certs aren't in use.

It very well could be finding the wrong realm based on DNS SRV
records. The logs should show you what the client discovered. Things
happen in multiple steps so perhaps there is a disconnect where the
right server is used in some, but not all, cases.

rob


ALL the problems were all related. Even after building brand new
servers, the problem persisted and then started cropping up with client
installs.

The solution traced to bad NSS packages. A simple yum downgrade nss
nss-sysinit nss-tools solved it.. Something is up with the 3.18 verion
and downgrading to 3.16 seems to have resolved. Should have known it
would all be related to an upgrade.  Sometimes a slightly older version
is best.

~Janelle


Can you open a bugzilla about this?

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


Re: [Freeipa-users] Crazy Cert problem?

2015-06-22 Thread Janelle

On 6/17/15 2:00 PM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 6:21 AM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 6:14 AM, Rob Crittenden wrote:

Janelle wrote:

Hi,

Had a server - named ipa001.example.com -- it was a replica. It
died. It
was re-installed. However, prior to the re-install it was saying the
wonderful:

TLS error -8172:Peer's certificate issuer has been marked as not
trusted
by the user.

It was rebuilt - new OS and doing a brand new ipa-server-install
(NOT a
replica or trying to join it back in to the existing ring of 
servers)

and at the end of the ipa-server-install - it gives:

Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Restarting the web server
Unable to set admin password Command ''/usr/bin/ldappasswd' '-h'
'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y'
'/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs'
'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned 
non-zero

exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
'--on-master' '--unattended' '--domain' 'example.com' '--server'
'ipa001.example.com' '--realm' 'example.com' '--hostname'
'ipa001.example.com'' returned non-zero exit status 1

and checking /var/log/ipaclient-install.log - the exact same TLS
error

But this is a brand new system, with brand new OS and the install 
was

ipa-server-install to install a clean server.

I don't understand how this is happening. There is no peer to 
be not

trusted?


What version of IPA and distro? (I don't think that probably has
anything to do with it, just curious in case it does eventually
matter).

What does /etc/openldap/ldap.conf look like? Normally it should have
TLS_CACERT /etc/ipa/ca.crt

Any chance you can share the server and client install logs?

rob

4.1.4 = IPA
CentOS 7.1

Oooh... Found something:  /etc/openldap/ldap.conf:

TLS_CACERTDIR/etc/openldap/certs

Going to investigate.
~J



That should be fine assuming there aren't any certs in there (and on a
brand new system I'd think you'd have empty NSS databases).

rob

So this gets interesting now...

Say you have 6 IPA servers, named ipa001-ipa006.example.com -- all
working fine.
Something happens to 002. It dies. You ipa-replica-manage del --clean
--force ipa002 to get rid of it.

A period of time, say a month, goes by. You have lost a couple of other
replicas for whatever reason, say 3 and 6. You decide you want to
rebuild. You start with 002 - leaving the others up and running because
you have users working. You firewall off 002 why you rebuild it.

You reinstall OS, reinstall FreeIPA. But no matter what, when you start
to configure IPA it comes up with the error of being untrusted. Now, you
try the same thing on 003 and 006. SAME problem.

For fun - you shutdown 005 and uninstall freeipa --unattended and then
try to re-install it. Guess what - no issues.

Is this somehow related to:
Same domain and realm names floating around the net - so is it querying
for a name somehow and one of the still running servers is saying -
NO NO NO -- that CERT is revoked!!! - even though it never tries to
connect to that server.

Or am I just thinking far too outside the box?  And this is exactly what
has happened. Rebuilding one of the servers that was never REMOVED is
working just fine.


You just jumped to a completely different scenario: from a fresh 
standalone install to a replica install. We should probably pick one 
and solve it.


I think the leap you're making is that the issue is that it notices 
some previous cert. A revoked service cert wouldn't have any effect as 
those service certs aren't in use.


It very well could be finding the wrong realm based on DNS SRV 
records. The logs should show you what the client discovered. Things 
happen in multiple steps so perhaps there is a disconnect where the 
right server is used in some, but not all, cases.


rob

ALL the problems were all related. Even after building brand new 
servers, the problem persisted and then started cropping up with client 
installs.


The solution traced to bad NSS packages. A simple yum downgrade nss 
nss-sysinit nss-tools solved it.. Something is up with the 3.18 verion 
and downgrading to 3.16 seems to have resolved. Should have known it 
would all be related to an upgrade.  Sometimes a slightly older version 
is best.


~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] Crazy Cert problem?

2015-06-17 Thread Rob Crittenden

Janelle wrote:

On 6/17/15 6:21 AM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 6:14 AM, Rob Crittenden wrote:

Janelle wrote:

Hi,

Had a server - named ipa001.example.com -- it was a replica. It
died. It
was re-installed. However, prior to the re-install it was saying the
wonderful:

TLS error -8172:Peer's certificate issuer has been marked as not
trusted
by the user.

It was rebuilt - new OS and doing a brand new ipa-server-install
(NOT a
replica or trying to join it back in to the existing ring of servers)
and at the end of the ipa-server-install - it gives:

Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Restarting the web server
Unable to set admin password Command ''/usr/bin/ldappasswd' '-h'
'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y'
'/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs'
'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned non-zero
exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
'--on-master' '--unattended' '--domain' 'example.com' '--server'
'ipa001.example.com' '--realm' 'example.com' '--hostname'
'ipa001.example.com'' returned non-zero exit status 1

and checking /var/log/ipaclient-install.log - the exact same TLS
error

But this is a brand new system, with brand new OS and the install was
ipa-server-install to install a clean server.

I don't understand how this is happening. There is no peer to be not
trusted?


What version of IPA and distro? (I don't think that probably has
anything to do with it, just curious in case it does eventually
matter).

What does /etc/openldap/ldap.conf look like? Normally it should have
TLS_CACERT /etc/ipa/ca.crt

Any chance you can share the server and client install logs?

rob

4.1.4 = IPA
CentOS 7.1

Oooh... Found something:  /etc/openldap/ldap.conf:

TLS_CACERTDIR/etc/openldap/certs

Going to investigate.
~J



That should be fine assuming there aren't any certs in there (and on a
brand new system I'd think you'd have empty NSS databases).

rob

So this gets interesting now...

Say you have 6 IPA servers, named ipa001-ipa006.example.com -- all
working fine.
Something happens to 002. It dies. You ipa-replica-manage del --clean
--force ipa002 to get rid of it.

A period of time, say a month, goes by. You have lost a couple of other
replicas for whatever reason, say 3 and 6. You decide you want to
rebuild. You start with 002 - leaving the others up and running because
you have users working. You firewall off 002 why you rebuild it.

You reinstall OS, reinstall FreeIPA. But no matter what, when you start
to configure IPA it comes up with the error of being untrusted. Now, you
try the same thing on 003 and 006. SAME problem.

For fun - you shutdown 005 and uninstall freeipa --unattended and then
try to re-install it. Guess what - no issues.

Is this somehow related to:
Same domain and realm names floating around the net - so is it querying
for a name somehow and one of the still running servers is saying -
NO NO NO -- that CERT is revoked!!! - even though it never tries to
connect to that server.

Or am I just thinking far too outside the box?  And this is exactly what
has happened. Rebuilding one of the servers that was never REMOVED is
working just fine.


You just jumped to a completely different scenario: from a fresh 
standalone install to a replica install. We should probably pick one and 
solve it.


I think the leap you're making is that the issue is that it notices some 
previous cert. A revoked service cert wouldn't have any effect as those 
service certs aren't in use.


It very well could be finding the wrong realm based on DNS SRV 
records. The logs should show you what the client discovered. Things 
happen in multiple steps so perhaps there is a disconnect where the 
right server is used in some, but not all, cases.


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


Re: [Freeipa-users] Crazy Cert problem?

2015-06-17 Thread Janelle

On 6/17/15 6:14 AM, Rob Crittenden wrote:

Janelle wrote:

Hi,

Had a server - named ipa001.example.com -- it was a replica. It died. It
was re-installed. However, prior to the re-install it was saying the
wonderful:

TLS error -8172:Peer's certificate issuer has been marked as not trusted
by the user.

It was rebuilt - new OS and doing a brand new ipa-server-install (NOT a
replica or trying to join it back in to the existing ring of servers)
and at the end of the ipa-server-install - it gives:

Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Restarting the web server
Unable to set admin password Command ''/usr/bin/ldappasswd' '-h'
'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y'
'/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs'
'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned non-zero
exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
'--on-master' '--unattended' '--domain' 'example.com' '--server'
'ipa001.example.com' '--realm' 'example.com' '--hostname'
'ipa001.example.com'' returned non-zero exit status 1

and checking /var/log/ipaclient-install.log - the exact same TLS 
error


But this is a brand new system, with brand new OS and the install was
ipa-server-install to install a clean server.

I don't understand how this is happening. There is no peer to be not
trusted?


What version of IPA and distro? (I don't think that probably has 
anything to do with it, just curious in case it does eventually matter).


What does /etc/openldap/ldap.conf look like? Normally it should have 
TLS_CACERT /etc/ipa/ca.crt


Any chance you can share the server and client install logs?

rob

4.1.4 = IPA
CentOS 7.1

Oooh... Found something:  /etc/openldap/ldap.conf:

TLS_CACERTDIR/etc/openldap/certs

Going to investigate.
~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] Crazy Cert problem?

2015-06-17 Thread Janelle

On 6/17/15 6:21 AM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 6:14 AM, Rob Crittenden wrote:

Janelle wrote:

Hi,

Had a server - named ipa001.example.com -- it was a replica. It 
died. It

was re-installed. However, prior to the re-install it was saying the
wonderful:

TLS error -8172:Peer's certificate issuer has been marked as not 
trusted

by the user.

It was rebuilt - new OS and doing a brand new ipa-server-install 
(NOT a

replica or trying to join it back in to the existing ring of servers)
and at the end of the ipa-server-install - it gives:

Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Restarting the web server
Unable to set admin password Command ''/usr/bin/ldappasswd' '-h'
'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y'
'/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs'
'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned non-zero
exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
'--on-master' '--unattended' '--domain' 'example.com' '--server'
'ipa001.example.com' '--realm' 'example.com' '--hostname'
'ipa001.example.com'' returned non-zero exit status 1

and checking /var/log/ipaclient-install.log - the exact same TLS
error

But this is a brand new system, with brand new OS and the install was
ipa-server-install to install a clean server.

I don't understand how this is happening. There is no peer to be not
trusted?


What version of IPA and distro? (I don't think that probably has
anything to do with it, just curious in case it does eventually 
matter).


What does /etc/openldap/ldap.conf look like? Normally it should have
TLS_CACERT /etc/ipa/ca.crt

Any chance you can share the server and client install logs?

rob

4.1.4 = IPA
CentOS 7.1

Oooh... Found something:  /etc/openldap/ldap.conf:

TLS_CACERTDIR/etc/openldap/certs

Going to investigate.
~J



That should be fine assuming there aren't any certs in there (and on a 
brand new system I'd think you'd have empty NSS databases).


rob
Well I was able to get another server stood up, but now if I go back to 
the server I was TRYING to set up and add it as a replica:


all good to here -- then
Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'ipa002.example.com':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

Connection from master to replica is OK.

Connection check OK
Using reverse zone(s) 202.161.17.in-addr.arpa.

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Unexpected error - see /var/log/ipareplica-install.log for details:
NetworkError: cannot connect to 'ldaps://ipa001.example.com': TLS error 
-8172:Peer's certificate issuer has been marked as not trusted by the user.



ipareplica-install.log below:


2015-06-17T13:37:48Z DEBUG stderr=
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/radiusproxy.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/role.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/rpcclient.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/service.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/user.py'
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py'
2015-06-17T13:37:48Z DEBUG importing all plugin modules in 
'/usr/lib/python2.7/site-packages/ipaserver/install/plugins'...
2015-06-17T13:37:48Z DEBUG importing plugin module 
'/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py'
2015-06-17T13:37:48Z DEBUG importing 

Re: [Freeipa-users] Crazy Cert problem?

2015-06-17 Thread Rob Crittenden

Janelle wrote:

Hi,

Had a server - named ipa001.example.com -- it was a replica. It died. It
was re-installed. However, prior to the re-install it was saying the
wonderful:

TLS error -8172:Peer's certificate issuer has been marked as not trusted
by the user.

It was rebuilt - new OS and doing a brand new ipa-server-install (NOT a
replica or trying to join it back in to the existing ring of servers)
and at the end of the ipa-server-install - it gives:

Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Restarting the web server
Unable to set admin password Command ''/usr/bin/ldappasswd' '-h'
'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y'
'/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs'
'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned non-zero
exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
'--on-master' '--unattended' '--domain' 'example.com' '--server'
'ipa001.example.com' '--realm' 'example.com' '--hostname'
'ipa001.example.com'' returned non-zero exit status 1

and checking /var/log/ipaclient-install.log - the exact same TLS error

But this is a brand new system, with brand new OS and the install was
ipa-server-install to install a clean server.

I don't understand how this is happening. There is no peer to be not
trusted?


What version of IPA and distro? (I don't think that probably has 
anything to do with it, just curious in case it does eventually matter).


What does /etc/openldap/ldap.conf look like? Normally it should have 
TLS_CACERT /etc/ipa/ca.crt


Any chance you can share the server and client install logs?

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


Re: [Freeipa-users] Crazy Cert problem?

2015-06-17 Thread Rob Crittenden

Janelle wrote:

On 6/17/15 6:14 AM, Rob Crittenden wrote:

Janelle wrote:

Hi,

Had a server - named ipa001.example.com -- it was a replica. It died. It
was re-installed. However, prior to the re-install it was saying the
wonderful:

TLS error -8172:Peer's certificate issuer has been marked as not trusted
by the user.

It was rebuilt - new OS and doing a brand new ipa-server-install (NOT a
replica or trying to join it back in to the existing ring of servers)
and at the end of the ipa-server-install - it gives:

Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Restarting the web server
Unable to set admin password Command ''/usr/bin/ldappasswd' '-h'
'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y'
'/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs'
'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned non-zero
exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
'--on-master' '--unattended' '--domain' 'example.com' '--server'
'ipa001.example.com' '--realm' 'example.com' '--hostname'
'ipa001.example.com'' returned non-zero exit status 1

and checking /var/log/ipaclient-install.log - the exact same TLS
error

But this is a brand new system, with brand new OS and the install was
ipa-server-install to install a clean server.

I don't understand how this is happening. There is no peer to be not
trusted?


What version of IPA and distro? (I don't think that probably has
anything to do with it, just curious in case it does eventually matter).

What does /etc/openldap/ldap.conf look like? Normally it should have
TLS_CACERT /etc/ipa/ca.crt

Any chance you can share the server and client install logs?

rob

4.1.4 = IPA
CentOS 7.1

Oooh... Found something:  /etc/openldap/ldap.conf:

TLS_CACERTDIR/etc/openldap/certs

Going to investigate.
~J



That should be fine assuming there aren't any certs in there (and on a 
brand new system I'd think you'd have empty NSS databases).


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


Re: [Freeipa-users] Crazy Cert problem?

2015-06-17 Thread Janelle

On 6/17/15 6:21 AM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 6:14 AM, Rob Crittenden wrote:

Janelle wrote:

Hi,

Had a server - named ipa001.example.com -- it was a replica. It 
died. It

was re-installed. However, prior to the re-install it was saying the
wonderful:

TLS error -8172:Peer's certificate issuer has been marked as not 
trusted

by the user.

It was rebuilt - new OS and doing a brand new ipa-server-install 
(NOT a

replica or trying to join it back in to the existing ring of servers)
and at the end of the ipa-server-install - it gives:

Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Restarting the web server
Unable to set admin password Command ''/usr/bin/ldappasswd' '-h'
'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y'
'/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs'
'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned non-zero
exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
'--on-master' '--unattended' '--domain' 'example.com' '--server'
'ipa001.example.com' '--realm' 'example.com' '--hostname'
'ipa001.example.com'' returned non-zero exit status 1

and checking /var/log/ipaclient-install.log - the exact same TLS
error

But this is a brand new system, with brand new OS and the install was
ipa-server-install to install a clean server.

I don't understand how this is happening. There is no peer to be not
trusted?


What version of IPA and distro? (I don't think that probably has
anything to do with it, just curious in case it does eventually 
matter).


What does /etc/openldap/ldap.conf look like? Normally it should have
TLS_CACERT /etc/ipa/ca.crt

Any chance you can share the server and client install logs?

rob

4.1.4 = IPA
CentOS 7.1

Oooh... Found something:  /etc/openldap/ldap.conf:

TLS_CACERTDIR/etc/openldap/certs

Going to investigate.
~J



That should be fine assuming there aren't any certs in there (and on a 
brand new system I'd think you'd have empty NSS databases).


rob

So this gets interesting now...

Say you have 6 IPA servers, named ipa001-ipa006.example.com -- all 
working fine.
Something happens to 002. It dies. You ipa-replica-manage del --clean 
--force ipa002 to get rid of it.


A period of time, say a month, goes by. You have lost a couple of other 
replicas for whatever reason, say 3 and 6. You decide you want to 
rebuild. You start with 002 - leaving the others up and running because 
you have users working. You firewall off 002 why you rebuild it.


You reinstall OS, reinstall FreeIPA. But no matter what, when you start 
to configure IPA it comes up with the error of being untrusted. Now, you 
try the same thing on 003 and 006. SAME problem.


For fun - you shutdown 005 and uninstall freeipa --unattended and then 
try to re-install it. Guess what - no issues.


Is this somehow related to:
Same domain and realm names floating around the net - so is it querying 
for a name somehow and one of the still running servers is saying - 
NO NO NO -- that CERT is revoked!!! - even though it never tries to 
connect to that server.


Or am I just thinking far too outside the box?  And this is exactly what 
has happened. Rebuilding one of the servers that was never REMOVED is 
working just fine.


~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