Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

[Michael Plemmons]

I also looked at RUVs and here is what I found.  I do not know if anything
here is helpful.

ldapsearch -ZZ -h ipa11.mgmt.crosschx.com -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
nsDS5ReplicaId: 1095
nsds50ruv: {replicageneration} 583445980060
nsds50ruv: {replica 1095 ldap://ipa11.mgmt.crosschx.com:389}
5865323f04470
nsds50ruv: {replica 86 ldap://ipa13.mgmt.crosschx.com:389}
58651fdb0056000
nsds50ruv: {replica 96 ldap://ipa11.mgmt.crosschx.com:389}
5834459c006
nsds50ruv: {replica 91 ldap://ipa13.mgmt.crosschx.com:389}
58344997005b000
nsds50ruv: {replica 97 ldap://ipa12.mgmt.crosschx.com:389}
583445c30061000
nsds50ruv: {replica 81 ldap://ipa12.mgmt.crosschx.com:389}
586529560051000

IPA12 - this is the problem node.
ldapsearch -ZZ -h ipa12.mgmt.crosschx.com -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
nsDS5ReplicaId: 81
nsds50ruv: {replicageneration} 583445980060
nsds50ruv: {replica 81 ldap://ipa12.mgmt.crosschx.com:389}
586529560051000
nsds50ruv: {replica 96 ldap://ipa11.mgmt.crosschx.com:389}
5834459c006
nsds50ruv: {replica 86 ldap://ipa13.mgmt.crosschx.com:389}
58651fdb0056000
nsds50ruv: {replica 91 ldap://ipa13.mgmt.crosschx.com:389}
58344997005b000
nsds50ruv: {replica 97 ldap://ipa12.mgmt.crosschx.com:389}
583445c30061000

ldapsearch -ZZ -h ipa13.mgmt.crosschx.com -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
nsDS5ReplicaId: 86
nsds50ruv: {replicageneration} 583445980060
nsds50ruv: {replica 86 ldap://ipa13.mgmt.crosschx.com:389}
58651fdb0056000
nsds50ruv: {replica 1095 ldap://ipa11.mgmt.crosschx.com:389}
5865323f04470
nsds50ruv: {replica 96 ldap://ipa11.mgmt.crosschx.com:389}
5834459c006
nsds50ruv: {replica 91 ldap://ipa13.mgmt.crosschx.com:389}
58344997005b000
nsds50ruv: {replica 97 ldap://ipa12.mgmt.crosschx.com:389}
583445c30061000
nsds50ruv: {replica 81 ldap://ipa12.mgmt.crosschx.com:389}
586529560051000





*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Wed, May 3, 2017 at 10:52 PM, Michael Plemmons <
michael.plemm...@crosschx.com> wrote:

> I ran another test.  I started IPA with the ignore service failure option
> and I tired doing ldap searches like this.
>
> ldapsearch -H ldaps://ipa12.mgmt.crosschx.com
>
> from both my laptop and from ipa11.mgmt and I get successful returns when
> logging in as the admin user and as the directory manager.
>
> I then looked closer at the LDAP access logs for the last time I tried to
> start up PKI and got the auth failure and i see this.
>
>
> [04/May/2017:02:22:45.859021005 +] conn=12 fd=101 slot=101 SSL
> connection from 10.71.100.92 to 10.71.100.92
> [04/May/2017:02:22:45.875672450 +] conn=12 TLS1.2 256-bit AES
> [04/May/2017:02:22:45.940908536 +] conn=12 op=0 BIND dn=""
> method=sasl version=3 mech=EXTERNAL
> [04/May/2017:02:22:45.942441120 +] conn=12 op=0 RESULT err=48 tag=97
> nentries=0 etime=0
>
> Is dn="" supposed to be empty?
>
>
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614.427.2411
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> On Wed, May 3, 2017 at 10:16 PM, Michael Plemmons <
> michael.plemm...@crosschx.com> wrote:
>
>> I realized that I was not very clear in my statement about testing with
>> ldapsearch.  I had initially run it without logging in with a DN.  I was
>> just running the local ldapsearch -x command.  I then tested on ipa12.mgmt
>> and ipa11.mgmt logging in with a full DN for the admin and "cn=Directory
>> Manager" from ipa12.mgmt (broken server) and ipa11.mgmt and both ldapsearch
>> command succeeded.
>>
>> I ran the following from ipa12.mgmt and ipa11.mgmt as a non root user.  I
>> also ran the command showing a line count for the output and the line
>> counts for each were the same when run from ipa12.mgmt and ipa11.mgmt.
>>
>> ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "DN" -w PASSWORD -b
>> "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn
>>
>> ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "cn=directory manager" -w
>> PASSWORD dn
>>
>>
>>
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
>> 614.427.2411
>> mike.plemm...@crosschx.com
>> www.crosschx.com
>>
>> On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons <
>> michael.plemm...@crosschx.com> wrote:
>>
>>> I have a three node IPA cluster.
>>>
>>> ipa11.mgmt - was a master over 6 months ago
>>> ipa13.mgmt - current master
>>> ipa12.mgmt
>>>
>>> ipa13 has agreements with ipa11 and ipa12.  ipa11 and ipa12 do not have
>>> agreements between each other.
>>>
>>> It appears that either ipa12.mgmt lost some level of its 

Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

[Michael Plemmons]

I ran another test.  I started IPA with the ignore service failure option
and I tired doing ldap searches like this.

ldapsearch -H ldaps://ipa12.mgmt.crosschx.com

from both my laptop and from ipa11.mgmt and I get successful returns when
logging in as the admin user and as the directory manager.

I then looked closer at the LDAP access logs for the last time I tried to
start up PKI and got the auth failure and i see this.


[04/May/2017:02:22:45.859021005 +] conn=12 fd=101 slot=101 SSL
connection from 10.71.100.92 to 10.71.100.92
[04/May/2017:02:22:45.875672450 +] conn=12 TLS1.2 256-bit AES
[04/May/2017:02:22:45.940908536 +] conn=12 op=0 BIND dn="" method=sasl
version=3 mech=EXTERNAL
[04/May/2017:02:22:45.942441120 +] conn=12 op=0 RESULT err=48 tag=97
nentries=0 etime=0

Is dn="" supposed to be empty?






*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Wed, May 3, 2017 at 10:16 PM, Michael Plemmons <
michael.plemm...@crosschx.com> wrote:

> I realized that I was not very clear in my statement about testing with
> ldapsearch.  I had initially run it without logging in with a DN.  I was
> just running the local ldapsearch -x command.  I then tested on ipa12.mgmt
> and ipa11.mgmt logging in with a full DN for the admin and "cn=Directory
> Manager" from ipa12.mgmt (broken server) and ipa11.mgmt and both ldapsearch
> command succeeded.
>
> I ran the following from ipa12.mgmt and ipa11.mgmt as a non root user.  I
> also ran the command showing a line count for the output and the line
> counts for each were the same when run from ipa12.mgmt and ipa11.mgmt.
>
> ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "DN" -w PASSWORD -b
> "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn
>
> ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "cn=directory manager" -w
> PASSWORD dn
>
>
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614.427.2411
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons <
> michael.plemm...@crosschx.com> wrote:
>
>> I have a three node IPA cluster.
>>
>> ipa11.mgmt - was a master over 6 months ago
>> ipa13.mgmt - current master
>> ipa12.mgmt
>>
>> ipa13 has agreements with ipa11 and ipa12.  ipa11 and ipa12 do not have
>> agreements between each other.
>>
>> It appears that either ipa12.mgmt lost some level of its replication
>> agreement with ipa13.  I saw some level because users / hosts were
>> replicated between all systems but we started seeing DNS was not resolving
>> properly from ipa12.  I do not know when this started.
>>
>> When looking at replication agreements on ipa12 I did not see any
>> agreement with ipa13.
>>
>> When I run ipa-replica-manage list all three hosts show has master.
>>
>> When I run ipa-replica-manage ipa11.mgmt I see ipa13.mgmt is a replica.
>>
>> When I run ipa-replica-manage ipa12.mgmt nothing returned.
>>
>> I ran ipa-replica-manage connect --cacert=/etc/ipa/ca.crt
>> ipa12.mgmt.crosschx.com ipa13.mgmt.crosschx.com on ipa12.mgmt
>>
>> I then ran the following
>>
>> ipa-replica-manage force-sync --from ipa13.mgmt.crosschx.com
>>
>> ipa-replica-manage re-initialize --from ipa13.mgmt.crosschx.com
>>
>> I was still seeing bad DNS returns when dig'ing against ipa12.mgmt.  I
>> was able to create user and DNS records and see the information replicated
>> properly across all three nodes.
>>
>> I then ran ipactl stop on ipa12.mgmt and then ipactl start on ipa12.mgmt
>> because I wanted to make sure everything was running fresh after the
>> changes above.  While IPA was staring up (DNS started) we were able to see
>> valid DNS queries returned but pki-tomcat would not start.
>>
>> I am not sure what I need to do in order to get this working.  I have
>> included the output of certutil and getcert below from all three servers as
>> well as the debug output for pki.
>>
>>
>> While the IPA system is coming up I am able to successfully run
>> ldapsearch -x as the root user and see results.  I am also able to login
>> with the "cn=Directory Manager" account and see results.
>>
>>
>> The debug log shows the following error.
>>
>>
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> 
>> [03/May/2017:21:22:01][localhost-startStop-1]: =  DEBUG SUBSYSTEM
>> INITIALIZED   ===
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> 
>> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
>> autoShutdown? false
>> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown
>> crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
>> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look
>> for cert for auto-shutdown support:auditSigningCert cert-pki-ca
>> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found
>> cert:auditSigningCert cert-pki-ca
>> 

Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

[Michael Plemmons]

I realized that I was not very clear in my statement about testing with
ldapsearch.  I had initially run it without logging in with a DN.  I was
just running the local ldapsearch -x command.  I then tested on ipa12.mgmt
and ipa11.mgmt logging in with a full DN for the admin and "cn=Directory
Manager" from ipa12.mgmt (broken server) and ipa11.mgmt and both ldapsearch
command succeeded.

I ran the following from ipa12.mgmt and ipa11.mgmt as a non root user.  I
also ran the command showing a line count for the output and the line
counts for each were the same when run from ipa12.mgmt and ipa11.mgmt.

ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "DN" -w PASSWORD -b
"cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn

ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "cn=directory manager" -w
PASSWORD dn






*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons <
michael.plemm...@crosschx.com> wrote:

> I have a three node IPA cluster.
>
> ipa11.mgmt - was a master over 6 months ago
> ipa13.mgmt - current master
> ipa12.mgmt
>
> ipa13 has agreements with ipa11 and ipa12.  ipa11 and ipa12 do not have
> agreements between each other.
>
> It appears that either ipa12.mgmt lost some level of its replication
> agreement with ipa13.  I saw some level because users / hosts were
> replicated between all systems but we started seeing DNS was not resolving
> properly from ipa12.  I do not know when this started.
>
> When looking at replication agreements on ipa12 I did not see any
> agreement with ipa13.
>
> When I run ipa-replica-manage list all three hosts show has master.
>
> When I run ipa-replica-manage ipa11.mgmt I see ipa13.mgmt is a replica.
>
> When I run ipa-replica-manage ipa12.mgmt nothing returned.
>
> I ran ipa-replica-manage connect --cacert=/etc/ipa/ca.crt
> ipa12.mgmt.crosschx.com ipa13.mgmt.crosschx.com on ipa12.mgmt
>
> I then ran the following
>
> ipa-replica-manage force-sync --from ipa13.mgmt.crosschx.com
>
> ipa-replica-manage re-initialize --from ipa13.mgmt.crosschx.com
>
> I was still seeing bad DNS returns when dig'ing against ipa12.mgmt.  I was
> able to create user and DNS records and see the information replicated
> properly across all three nodes.
>
> I then ran ipactl stop on ipa12.mgmt and then ipactl start on ipa12.mgmt
> because I wanted to make sure everything was running fresh after the
> changes above.  While IPA was staring up (DNS started) we were able to see
> valid DNS queries returned but pki-tomcat would not start.
>
> I am not sure what I need to do in order to get this working.  I have
> included the output of certutil and getcert below from all three servers as
> well as the debug output for pki.
>
>
> While the IPA system is coming up I am able to successfully run ldapsearch
> -x as the root user and see results.  I am also able to login with the
> "cn=Directory Manager" account and see results.
>
>
> The debug log shows the following error.
>
>
> [03/May/2017:21:22:01][localhost-startStop-1]:
> 
> [03/May/2017:21:22:01][localhost-startStop-1]: =  DEBUG SUBSYSTEM
> INITIALIZED   ===
> [03/May/2017:21:22:01][localhost-startStop-1]:
> 
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
> autoShutdown? false
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown
> crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look
> for cert for auto-shutdown support:auditSigningCert cert-pki-ca
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found
> cert:auditSigningCert cert-pki-ca
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init
> id=debug
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized
> debug
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem
> id=log
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init
> id=log
> [03/May/2017:21:22:01][localhost-startStop-1]: Creating
> RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit)
> [03/May/2017:21:22:01][localhost-startStop-1]: Creating
> RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system)
> [03/May/2017:21:22:01][localhost-startStop-1]: Creating
> RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions)
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
> autoShutdown? false
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown
> crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look
> for cert for auto-shutdown support:auditSigningCert cert-pki-ca
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found
> cert:auditSigningCert cert-pki-ca
> 

Re: [Freeipa-users] External cert with correct CSR?

[Fraser Tweedale]

On Tue, May 02, 2017 at 11:10:12AM -0500, Kat wrote:
> Yeah, after I sent this email, I realized what I was trying to do and that,
> "Oh wait, this is not really going to work."
> 
Indeed.  This feature is usually used to chain an IPA CA into an
organisation's existing PKI, which is controlled by the
organisation, thus they can add whatever they need to the cert
regardless of what is/is not asserted by the CSR).

Cheers,
Fraser

> For what it is worth - version on RHEL 7.3 - 4.4.0-14.el7_3.7
> 
> -K
> 
> On 5/2/17 11:04 AM, Rob Crittenden wrote:
> > Kat wrote:
> > > Hi all,
> > > 
> > > I am somewhat confused trying to get the process of using an external
> > > cert for IPA.
> > > 
> > > If I follow step 1:
> > > ipa-server-install -a Secret123 -p Secret123 -r EXAMPLE.COM
> > > --external-ca -U
> > > 
> > > This does indeed generate a CSR, but trying to do anything with this CSR
> > > has no success since it is not properly formed with all info.  In
> > > otherwords, ipa does not add country, state, location, etc. If I submit
> > > this CSR to any cert company, it will of course, complain. Is there a
> > > way to get this right? Or am I just missing something here?
> > > 
> > What cert company are you trying to get to sign this? This is a CA cert,
> > I don't know that any of the major ones will sign this, at least not
> > without a huge check.
> > 
> > What version of IPA?
> > 
> > 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

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

[Ian Harding]

Is there any way this can be made to work?  This server does not exist
in real life or seemingly in FreeIPA, but a ghost of it does.

ianh@vm-ian-laptop:~$ ipa server-find freeipa-dal.bpt.rocks

1 IPA server matched

  Server name: freeipa-dal.bpt.rocks
  Min domain level: 0
  Max domain level: 0

Number of entries returned 1

ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks
Removing freeipa-dal.bpt.rocks from replication topology, please wait...
ipa: ERROR: freeipa-dal.bpt.rocks: server not found
ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks --force
Removing freeipa-dal.bpt.rocks from replication topology, please wait...
ipa: ERROR: freeipa-dal.bpt.rocks: server not found
ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks --force
--continue
Removing freeipa-dal.bpt.rocks from replication topology, please wait...
ipa: WARNING: Forcing removal of freeipa-dal.bpt.rocks
-
Deleted IPA server ""
-
  Failed to remove: freeipa-dal.bpt.rocks
ianh@vm-ian-laptop:~$

- Ian

-- 
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] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

[Michael Plemmons]

I have a three node IPA cluster.

ipa11.mgmt - was a master over 6 months ago
ipa13.mgmt - current master
ipa12.mgmt

ipa13 has agreements with ipa11 and ipa12.  ipa11 and ipa12 do not have
agreements between each other.

It appears that either ipa12.mgmt lost some level of its replication
agreement with ipa13.  I saw some level because users / hosts were
replicated between all systems but we started seeing DNS was not resolving
properly from ipa12.  I do not know when this started.

When looking at replication agreements on ipa12 I did not see any agreement
with ipa13.

When I run ipa-replica-manage list all three hosts show has master.

When I run ipa-replica-manage ipa11.mgmt I see ipa13.mgmt is a replica.

When I run ipa-replica-manage ipa12.mgmt nothing returned.

I ran ipa-replica-manage connect --cacert=/etc/ipa/ca.crt
ipa12.mgmt.crosschx.com ipa13.mgmt.crosschx.com on ipa12.mgmt

I then ran the following

ipa-replica-manage force-sync --from ipa13.mgmt.crosschx.com

ipa-replica-manage re-initialize --from ipa13.mgmt.crosschx.com

I was still seeing bad DNS returns when dig'ing against ipa12.mgmt.  I was
able to create user and DNS records and see the information replicated
properly across all three nodes.

I then ran ipactl stop on ipa12.mgmt and then ipactl start on ipa12.mgmt
because I wanted to make sure everything was running fresh after the
changes above.  While IPA was staring up (DNS started) we were able to see
valid DNS queries returned but pki-tomcat would not start.

I am not sure what I need to do in order to get this working.  I have
included the output of certutil and getcert below from all three servers as
well as the debug output for pki.


While the IPA system is coming up I am able to successfully run ldapsearch
-x as the root user and see results.  I am also able to login with the
"cn=Directory Manager" account and see results.


The debug log shows the following error.


[03/May/2017:21:22:01][localhost-startStop-1]:

[03/May/2017:21:22:01][localhost-startStop-1]: =  DEBUG SUBSYSTEM
INITIALIZED   ===
[03/May/2017:21:22:01][localhost-startStop-1]:

[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
autoShutdown? false
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown
crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look for
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init id=debug
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized debug
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem
id=log
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init
id=log
[03/May/2017:21:22:01][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit)
[03/May/2017:21:22:01][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system)
[03/May/2017:21:22:01][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions)
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
autoShutdown? false
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown
crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look for
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init id=log
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized log
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem
id=jss
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init
id=jss
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
autoShutdown? false
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown
crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look for
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init id=jss
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized jss
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem
id=dbs
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init
id=dbs
[03/May/2017:21:22:01][localhost-startStop-1]: DBSubsystem: init()
 mEnableSerialMgmt=true

[Freeipa-users] Password history based on age, not count?

[Patrick Hemmer]

Would it be reasonable to request a feature for FreeIPA to enforce
password history reuse based on age, instead of a count? Meaning
configure FreeIPA to enforce that a password cannot be reused within the
last 1 year? Then we could remove the minimum time between password
changes, and not worry about people cycling through X passwords to be
able to reuse one.

When we were using OpenLDAP for user account management, I wrote an
extension for it to do just that and it was rather convenient (not
having to deal with an annoying min-change-time). The whole
min-time-between-changes, and number-of-passwords-in-history thing has
always seemed like a hack to accomplish the true goal of preventing
users from reusing passwords within a certain amount of time.

-Patrick
-- 
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] CA lost on migration

[Marius Bjørnstad]

Hi,

I have migrated some FreeIPA servers from 3.0.0-51 to 4.4.0-14 by adding new 
replicas. There were a lot of issues, and I'm strugglig a bit with a 
configuration management system set up by a central IT department, which 
overrides files like sssd.conf, and I have to make exceptions to the policy. I 
hope someone could take the time to help me with this anyway.

I was able to join both new RHEL 7 machines, and remove one of the old RHEL 6 
machines, but then I couldn't remove the last one, and couldn't install the CA 
on any of the new masters. I (perhaps stupidly) removed the old server using 
ldapdelete, based on this thread: 
https://www.redhat.com/archives/freeipa-users/2012-June/msg00382.html. I 
thought that if I could get rid of the old stuff, I may be able to successfully 
promote one of the new servers to CA master. The command to install the CA 
almost completed successfully on the first master, but stopped on one of the 
last steps.

Now I get:
# ipa-ca-install
CA is already installed on this host.

It is clear that the CA is not installed. I get errors in 
/var/log/httpd/error_log for hosts requesting certs, and getting NotFound.
ipa: INFO: [xmlserver] host/x@DOMAIN: cert_request(u'MIIDnzCCaoc...


I then removed and uninstalled the other master, which did not have a CA, 
thinking it could get going with a reinstall. However, the installation fails

ipa : ERROR  Cannot issue certificates: a CA is not installed. Use the 
--http-cert-file, --dirsrv-cert-file options to provide custom certificates.

(there may be some typos in the error messages, since I'm copying from an 
air-gapped network)

Is there any way I can manually resurrect the CA? I have the files left over on 
the original (version 3) master, but did do an uninstall. If that's not 
possible, is there any way to migrate the users to a new domain with exactly 
the same name (this would be less convenient, if it's actually possible, since 
I have to re-enroll all the clients).

Thanks,
Marius Bjørnstad


-- 
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] Can't make replica with CA due to LDAP 'replication manager' user not found error

[Chris Dagdigian]

Any guidance for this one?

Summary - this seems to be the fatal error that causes the CA setup on 
the replica to fail:


May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection: 
The specified user cn=Replication Manager 
masterAgreement1-usaeilidmp002.XXX.org-pki-tomcat,cn=config does not exist



May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine: init(): 
password test execution failed for replicationdbwith NO_SUCH_USER.  This 
may not be a latest instance.  Ignoring ..



More details ...


Trying to build a replica with CA duties for the first time.

It hangs here during the replica install process:


ipa : DEBUGstderr=
ipa : DEBUGwait_for_open_ports: localhost [8080, 8443] 
timeout 300

ipa : DEBUGWaiting until the CA is running
ipa : DEBUGrequest POST 
http://usaeilidmp002.XXX.org:8080/ca/admin/ca/getStatus

ipa : DEBUGrequest body ''


However the root cause seems to be that the CA won't start because 
something is wrong with an LDAP replication manager user?


When I restart the pki-tomcatd service the replica install STDOUT 
refreshes the above status. After the 3rd attempt it triggers the fatal 
"CA will not start after 300 seconds" error




From the logs:

# systemctl status pki-tomcatd@pki-tomcat.service
● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat
   Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled; 
vendor preset: disabled)

   Active: active (running) since Wed 2017-05-03 15:09:04 UTC; 40s ago
  Process: 3843 ExecStop=/usr/libexec/tomcat/server stop (code=exited, 
status=1/FAILURE)
  Process: 3880 ExecStartPre=/usr/bin/pkidaemon start %i (code=exited, 
status=0/SUCCESS)

 Main PID: 3993 (java)
   CGroup: 
/system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd@pki-tomcat.service
   └─3993 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java 
-DRESTEASY_LIB=/usr/share/java/resteasy-base 
-Djava.library.path=/usr/lib64/nuxwdog-jni -classpath /usr/share/...


May 03 15:09:08 usaeilidmp002.XXX.org server[3993]: 
SSLAuthenticatorWithFallback: Setting container
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: 
SSLAuthenticatorWithFallback: Initializing authenticators
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: 
SSLAuthenticatorWithFallback: Starting authenticators
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: 
CMSEngine.initializePasswordStore() begins
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: 
CMSEngine.initializePasswordStore(): tag=internaldb
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection 
connecting to usaeilidmp002.XXX.org:389
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: 
CMSEngine.initializePasswordStore(): tag=replicationdb
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection 
connecting to usaeilidmp002.XXX.org:389
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection: 
The specified user cn=Replication Manager 
masterAgreement1-usaeilidmp002.XXX...not exist
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine: init(): 
password test execution failed for replicationdbwith NO_SUCH_USER.  This 
may not...noring ..

Hint: Some lines were ellipsized, use -l to show in full.






--
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 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"

[Brian Candler]

It turns out we had another 16.04 machine which was working fine. But as 
soon as I updated its sudo from 1.8.16-0ubuntu1.2 to 1.8.16-0ubuntu1.3, 
it stopped working too.


So it looks like I have a reproducing case for this and I can 
investigate further - I suspect it's a behaviour change from this fix:

https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666

--
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] GSSAPI authentication from trusted AD domain

[Tiemen Ruiten]

Tickets on the FreeIPA host after connecting (with a password):

[adm.tie...@clients.rdmedia.com@neodymium ~]$ klist
Ticket cache: KEYRING:persistent:998801112:krb_ccache_ZzERoB1
Default principal: adm.tie...@clients.rdmedia.com

Valid starting   Expires  Service principal
05/03/2017 11:26:03  05/03/2017 21:26:03  krbtgt/
clients.rdmedia@clients.rdmedia.com
renew until 05/04/2017 11:26:03



Tickets on the AD laptop after a connection attempt:

C:\Users\adm.tiemen.CLIENTS>klist

Current LogonId is 0:0x587aa

Cached Tickets: (2)

#0> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM
Server: krbtgt/CLIENTS.RDMEDIA.COM @ CLIENTS.RDMEDIA.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e1 -> forwardable renewable initial
pre_authent name_canonicalize
Start Time: 5/3/2017 11:12:46 (local)
End Time:   5/3/2017 21:12:46 (local)
Renew Time: 5/10/2017 11:12:46 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: vm-win-01.clients.rdmedia.com

#1> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM
Server: LDAP/vm-win-01.clients.rdmedia.com/clients.rdmedia.com @
CLIENTS.RDMEDIA.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a5 -> forwardable renewable pre_authent
ok_as_delegate name_canonicalize
Start Time: 5/3/2017 11:12:46 (local)
End Time:   5/3/2017 21:12:46 (local)
Renew Time: 5/10/2017 11:12:46 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: vm-win-01.clients.rdmedia.com




On 2 May 2017 at 19:45, Tiemen Ruiten  wrote:

> It's a CentOS 7.3 host, the version of sssd is 1.14.0, so there's no need
> for mapping. However on the AD host:
>
> Microsoft Windows [Version 6.3.9600]
>
> (c) 2013 Microsoft Corporation. All rights reserved.
>
>
> adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen>klist
>
>
> Current LogonId is 0:0x603b58
>
>
> Cached Tickets: (0)
>
>
> adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen>
>
> Note that this is the domain controller and I'm logged in using the
> experimental Win32-OpenSSH server. Not sure if that makes a difference. I
> am not currently in the office, so unfortunately can't turn on the only
> joined laptop in this domain.
>
> How can I ensure a proper ticket is generated?
>
> On 2 May 2017 at 18:25, Sumit Bose  wrote:
>
>> On Tue, May 02, 2017 at 05:46:34PM +0200, Tiemen Ruiten wrote:
>> > I think I just realised that my expectation may be wrong: GSSAPI login
>> with
>> > a FreeIPA user logged in on an AD host to a FreeIPA host works. So is it
>> > correct to also expect passwordless login with an AD user to a FreeIPA
>> host?
>>
>> The AD user case should work as well.
>>
>> First please send the SSSD version you use on the IPA client,
>> alternatively you can check if
>> /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists or not. This
>> would tell if SSSD can map the user name to the Kerberos principal of if
>> additional configuration is needed.
>>
>> On the AD host please check after trying to connect with ssh if there is
>> a proper service ticket for the IPA client by calling 'klist' in cmd.exe
>> or PowerShell.
>>
>> bye,
>> Sumit
>>
>> >
>> > On 2 May 2017 at 17:40, Jason B. Nance  wrote:
>> >
>> > > Hi Tiemen,
>> > >
>> > > To be clear, what I'm trying to do: log in from an AD account
>> > > (adm.tiemen), from an AD host (leon.clients.rdmedia.com) to a FreeIPA
>> > > host (neodymium.test.ams.i.rdmedia.com) with the same AD account. I
>> > > expect to be logged in through GSSAPI, instead I get a password
>> prompt.
>> > >
>> > > I'm assuming that you are coming from a Windows client that is domain
>> > > joined and logged into that Windows client with the same domain
>> credentials
>> > > that you are using to connect to the IPA-joined host.  Do you also
>> have
>> > > your SSH client configured to attempt GSSAPI?  It appears that you do
>> from
>> > > the logs you provided but I'm just double-checking.
>> > >
>> > > In my setup I've found that this feature does not work all of the
>> time.
>> > > I've not yet been able to track it down and I'm assuming it has
>> something
>> > > to do with connections to domain controllers timing out, but at this
>> point
>> > > that is speculation.
>> > >
>> > > So to answer your question, yes, that should work.  Sorry I don't have
>> > > more information for you, I guess I'm basically "me too"ing your post.
>> > >
>> > > Regards,
>> > >
>> > > j
>> > >
>> > > Is this supposed to work? Did I miss something?
>> > >
>> > > Below the SSH log from the FreeIPA host with LogLevel DEBUG3:
>> > >
>> > > May  2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK
>> > > May  2 17:10:32 neodymium sshd[572]: debug1: Forked child 752.
>> > > May  2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state:

Re: [Freeipa-users] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"

[Brian Candler]

> do you have 'sudo: files sss" or "sudoers: files sss"? The former 
doesn't do anything, the latter is correct.


My mistake, I meant

sudoers: files sss

But oddly, out of the three 16.04 boxes I set up and enrolled, it was 
missing on one of them - and this happened to be the one I was checking 
logs on :-(  (However, sudo fails in the same way on all three machines)


So after adding this I've rechecked logs.

/var/log/sudo-debug is the same, in particular it still shows "policy 
plugin returns 0" and nothing after.


With sss_debuglevel 5, /var/log/sssd/sssd_IPA.EXAMPLE.COM.log has

...
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): ruser: brian.candler
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): rhost:
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): authtok type: 0
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): newauthtok type: 0
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): priv: 0
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): cli_pid: 22709
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): logon name: not set
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[ipa_hostgroup_info_done] (0x0200): Dereferenced host group: normal_hosts
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[ipa_hostgroup_info_done] (0x0200): Dereferenced host group: 
development_hosts
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[hbac_get_category] (0x0200): Category is set to 'all'.
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule 
[allow_normal_hosts]
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) 
[Success]
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) 
[Success]
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[be_pam_handler_callback] (0x0100): Sending result [0][IPA.EXAMPLE.COM]
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[be_pam_handler_callback] (0x0100): Sent result [0][IPA.EXAMPLE.COM]


("allow_normal_hosts" is indeed the name of the rule in FreeIPA database)

sssd.log has:

(Wed May  3 08:50:35 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): 
Received client version [1].
(Wed May  3 08:50:35 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): 
Offered version [1].
(Wed May  3 08:50:35 2017) [sssd[nss]] [sss_parse_name_for_domains] 
(0x0200): name 'root' matched without domain, user is root
(Wed May  3 08:50:35 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0100): 
Requesting info for [root] from []
(Wed May  3 08:50:35 2017) [sssd[nss]] [nss_cmd_initgroups_search] 
(0x0080): No matching domain found for [root], fail!
(Wed May  3 08:50:37 2017) [sssd[nss]] [client_recv] (0x0200): Client 
disconnected!


(Hmm, suspicious that error about "root" ??)

sssd_sudo.log has:

(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_cmd_get_version] (0x0200): 
Received client version [1].
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_cmd_get_version] (0x0200): 
Offered version [1].
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sudosrv_cmd_parse_query_done] 
(0x0200): Requesting default options for [brian.candler] from []
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sudosrv_get_user] (0x0200): 
Requesting info about [brian.cand...@ipa.example.com]
(Wed May  3 08:50:35 2017) [sssd[sudo]] 
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=brian.candler)(sudoUser=#121103)(sudoUser=%security_administrators)(sudoUser=%admins)(sudoUser=%network_readonly)(sudoUser=%vpn)(sudoUser=%system_administrators)(sudoUser=%ipausers)(sudoUser=%staff)(sudoUser=%brian.candler)(sudoUser=+*))(&(dataExpireTimestamp<=1493801435)))]
(Wed May  3 08:50:35 2017) [sssd[sudo]] 
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(name=defaults)))]
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sudosrv_cmd_parse_query_done] 
(0x0200): Requesting rules for [brian.candler] from []
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sudosrv_get_user] (0x0200): 
Requesting info about 

Re: [Freeipa-users] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"

[Jakub Hrozek]

On Wed, May 03, 2017 at 09:04:05AM +0100, Brian Candler wrote:
> Hi,
> 
> I have FreeIPA set up under CentOS 7.  When I use freeipa-client to add an
> ubuntu 14.04 client it works fine (*). However when do the same with ubuntu
> 16.04, sudo always refuses to run:
> 
> $ sudo -s
> [sudo] password for brian.candler:
> brian.candler is not allowed to run sudo on api-dev.int.example.com.  This
> incident will be reported.
> 
> I have a simple one-entry sudo policy which says that for all users in
> groups X and Y, on all hosts, run all commands.  (**)
> 
> If I crank up sudo logging by setting this in /etc/sudo.conf:
> 
> Debug sudo /var/log/sudo-debug all@info
> 
> then on the working 14.04 machine I see
> 
> ... various settings ...
> May  2 22:05:27 sudo[19175] settings: plugin_dir=/usr/lib/sudo/
> May  2 22:05:27 sudo[19175] user_info: user=brian.candler
> May  2 22:05:27 sudo[19175] user_info: pid=19175
> ... lots more user_info, perms, netgroups etc ...
> May  2 22:05:29 sudo[19175] policy plugin returns 1
> ...
> 
> but on the failing 16.04 machine I see only this:
> 
> May  3 07:44:56 sudo[21118] will restore signal 13 on exec
> May  3 07:44:56 sudo[21118] comparing dev 34817 to /dev/pts/1: match! @
> sudo_ttyname_dev() ./ttyname.c:336
> May  3 07:44:56 sudo[21118] settings: run_shell=true
> May  3 07:44:56 sudo[21118] settings: progname=sudo
> May  3 07:44:56 sudo[21118] settings: network_addrs=x.x.x.x/255.255.255.0
> :::::230/:::::::
> fe80::1:::/:::::
> May  3 07:44:56 sudo[21118] settings: plugin_dir=/usr/lib/sudo/
> May  3 07:44:58 sudo[21118] policy plugin returns 0
> 
> That's all that gets logged - nothing more.  It seems that a return of 0
> means failure:
> 
> https://www.sudo.ws/man/1.8.15/sudo_plugin.man.html
> 
> "open()
> ...
> Returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if
> there was a usage error."
> 
> But I have no idea what sort of failure or why.
> 
> /var/log/auth.log shows:
> 
> May  3 08:00:14 api-dev sudo: pam_unix(sudo:auth): authentication failure;
> logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1
> ruser=brian.candler rhost=  user=brian.candler
> May  3 08:00:14 api-dev sudo: pam_sss(sudo:auth): authentication success;
> logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1
> ruser=brian.candler rhost= user=brian.candler
> May  3 08:00:14 api-dev sudo: brian.candler : user NOT in sudoers ;
> TTY=pts/1 ; PWD=/home/brian.candler ; USER=root ; COMMAND=/bin/bash
> 
> (which shows I gave the correct FreeIPA password, but not why the sudoers
> lookup failed)
> 
> I really can't see where else to look. Both machines have "sudo: files sss"
> in /etc/nsswitch.conf, and both have the same /etc/sssd/sssd.conf.  Setting
> "sss_debuglevel 7" and "sss_cache -UG" shows a lot of noise but no obvious
> errors.

do you have 'sudo: files sss" or "sudoers: files sss"? The former
doesn't do anything, the latter is correct.

if you crank up debugging in the sudo section in sssd.conf do you see
any activity at all?

do you have '/usr/lib64/libsss_sudo.so' installed? On fedora/rhel, this
is provided by libsss_sudo, I don't know what provides it on Debian.

> 
> I've also upgraded to the latest sudo_1.8.19-3_amd64.deb package from
> https://www.sudo.ws/download.html, but this makes no difference.
> 
> Has anyone seen this problem before, or have some ideas where else to look?
> 
> Thanks,
> 
> Brian Candler.
> 
> 
> (*) In Ubuntu 14.04 I had to manually add sudo to the list of sssd services:
> 
> |[sssd]|
> |services = nss, pam, ssh, sudo|
> 
> but this was done automatically by freeipa-client in Ubuntu 16.04.
> 
> (**) Therefore I'm pretty sure this is not the netgroups problem, for which
> the fix has been released anyway:
> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666

> -- 
> 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] LDAP size limit and the FreeIPA web UI

[Petr Vobornik]

On 05/02/2017 10:50 PM, Jay Fenlason wrote:

One of my users is having trouble because the FreeIPA web interface
does not work well with a DNS zone that contains more than 2000
entries.  When he goes to Network Services->DNS->DNS Zones and selects
the problematic zone, he gets an error popup saying the results were
truncated because the number of entries exceeds the LDAP server's
search limit.  I went in to IPA Server->Configuration and changed the
Search size limit, but raising it over 2000 requires manually
modifying the LDAP server configuration.

Are there any plans to improve the web UI so that it does not require
such a large size limit when viewing a DNS zone?  Are there
other GUI tools that can be used to view/edit the DNS zone data (and
that don't also suffer from hitting these search size limits)?

I'm using ipa-server-4.4.0-14.el7.centos.6.x86_64 if it matters.

 -- JF



Web UI has the same size limits which are imposed by LDAP server for the 
authenticated user.


In 4.5 version the warning was changed to be less annoying.

There are currently no specific plans to change Web UI in this area. A 
think which was considered is to disable paging for post pages (e.g. 
user and host search) and rely more on size-limits and searching. The 
reasoning is that browser through a lot of records is not very usable 
and it is better to search.


So I would ask in different way. How would you envision the Web UI 
should behave for so many records? E.g. just in DNS area.


--
Petr Vobornik


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

[Freeipa-users] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"

[Brian Candler]

Hi,

I have FreeIPA set up under CentOS 7.  When I use freeipa-client to add 
an ubuntu 14.04 client it works fine (*). However when do the same with 
ubuntu 16.04, sudo always refuses to run:


$ sudo -s
[sudo] password for brian.candler:
brian.candler is not allowed to run sudo on api-dev.int.example.com.  
This incident will be reported.


I have a simple one-entry sudo policy which says that for all users in 
groups X and Y, on all hosts, run all commands.  (**)


If I crank up sudo logging by setting this in /etc/sudo.conf:

Debug sudo /var/log/sudo-debug all@info

then on the working 14.04 machine I see

... various settings ...
May  2 22:05:27 sudo[19175] settings: plugin_dir=/usr/lib/sudo/
May  2 22:05:27 sudo[19175] user_info: user=brian.candler
May  2 22:05:27 sudo[19175] user_info: pid=19175
... lots more user_info, perms, netgroups etc ...
May  2 22:05:29 sudo[19175] policy plugin returns 1
...

but on the failing 16.04 machine I see only this:

May  3 07:44:56 sudo[21118] will restore signal 13 on exec
May  3 07:44:56 sudo[21118] comparing dev 34817 to /dev/pts/1: match! @ 
sudo_ttyname_dev() ./ttyname.c:336

May  3 07:44:56 sudo[21118] settings: run_shell=true
May  3 07:44:56 sudo[21118] settings: progname=sudo
May  3 07:44:56 sudo[21118] settings: 
network_addrs=x.x.x.x/255.255.255.0 
:::::230/::::::: 
fe80::1:::/:::::

May  3 07:44:56 sudo[21118] settings: plugin_dir=/usr/lib/sudo/
May  3 07:44:58 sudo[21118] policy plugin returns 0

That's all that gets logged - nothing more.  It seems that a return of 0 
means failure:


https://www.sudo.ws/man/1.8.15/sudo_plugin.man.html

"open()
...
Returns 1 on success, 0 on failure, -1 if a general error occurred, or 
-2 if there was a usage error."


But I have no idea what sort of failure or why.

/var/log/auth.log shows:

May  3 08:00:14 api-dev sudo: pam_unix(sudo:auth): authentication 
failure; logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 
ruser=brian.candler rhost=  user=brian.candler
May  3 08:00:14 api-dev sudo: pam_sss(sudo:auth): authentication 
success; logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 
ruser=brian.candler rhost= user=brian.candler
May  3 08:00:14 api-dev sudo: brian.candler : user NOT in sudoers ; 
TTY=pts/1 ; PWD=/home/brian.candler ; USER=root ; COMMAND=/bin/bash


(which shows I gave the correct FreeIPA password, but not why the 
sudoers lookup failed)


I really can't see where else to look. Both machines have "sudo: files 
sss" in /etc/nsswitch.conf, and both have the same /etc/sssd/sssd.conf.  
Setting "sss_debuglevel 7" and "sss_cache -UG" shows a lot of noise but 
no obvious errors.


I've also upgraded to the latest sudo_1.8.19-3_amd64.deb package from 
https://www.sudo.ws/download.html, but this makes no difference.


Has anyone seen this problem before, or have some ideas where else to look?

Thanks,

Brian Candler.


(*) In Ubuntu 14.04 I had to manually add sudo to the list of sssd services:

|[sssd]|
|services = nss, pam, ssh, sudo|

but this was done automatically by freeipa-client in Ubuntu 16.04.

(**) Therefore I'm pretty sure this is not the netgroups problem, for 
which the fix has been released anyway:

https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666
-- 
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