Re: [Freeipa-users] Error in selinux child: libsemanage can't parse spaces in AD user names

[Lachlan Musicman]

On 18 July 2016 at 18:26, Jakub Hrozek  wrote:

> On Mon, Jul 18, 2016 at 09:33:35AM +1000, Lachlan Musicman wrote:
> > Ok, I've just spoken with my colleague that has been involved in the IPA
> > roll out, and he said he thought that override_space wasn't compatible
> with
> > ID overrides?
>
> I haven't tested that to be honest. But just using my knowledge of the
> code as a basis, I would say the two should be compatible, especially
> with 1.14.0 where we decoupled the output from how we store users. But
> again, I haven't tested any of this.
>
> >
> > Either way, since we have a working system we are reticent to make too
> many
> > changes - soon we will have a test system in place and I will be able to
> > check it then?
>
> selinux_provider=none should be an easy workaround if you don't use the
> SELinux labels. I still have an item on my todo list to test this
> locally, I think I will get to that this week.
>


For what it's worth, we implemented the override_space=_ option.

This has failed, of course, because we had a user with an _ in their
username, and sssd went looking for test user instead of test_user, which
caused all kinds of issues.

We have gone back to selinux_provider=none

L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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 Error 4301: CertificateOperationError

[Fraser Tweedale]

On Mon, Aug 22, 2016 at 11:52:46PM +, Z D wrote:
> Hello,
>
> There is the error on ver 4.2 while viewing certs: "IPA Error
> 4301: CertificateOperationError", next it read " Certificate
> operation cannot be completed: Unable to communicate with CMS
> ([Errno 113] No route to host)".
> 
> I suspect you'll be asking for below two commands, here are results.
> 
> # ipa cert-show 1
>   Certificate: 
> MIIDlzCCAn+gAwIBAgIBATANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQKDA1VUy5P
> ..shortened ...
> H6S7tS4pT9w77K8=
>   Subject: CN=Certificate Authority,O=COMP.COM
>   Issuer: CN=Certificate Authority,O=COMP.COM
>   Not Before: Wed Aug 17 17:20:41 2016 UTC
>   Not After: Sun Aug 17 17:20:41 2036 UTC
>   Fingerprint (MD5): 00:a5:2c:2d:ea:c8:27:33:62:35:75:53:12:6a:0d:c1
>   Fingerprint (SHA1): 
> d1:58:78:83:31:b8:ad:ae:af:2c:e7:05:44:67:6e:3a:37:8c:00:1a
>   Serial number (hex): 0x1
>   Serial number: 1
> 
> # ipactl restart
> Restarting Directory Service
> Restarting krb5kdc Service
> Restarting kadmin Service
> Restarting named Service
> Restarting ipa_memcached Service
> Restarting httpd Service
> Restarting ipa-otpd Service
> Restarting ipa-dnskeysyncd Service
> ipa: INFO: The ipactl command was successful
> 
> Any help is appreciated, thanks
> Zarko
>

"while viewing certs" -> do you mean in the IPA Web UI?

The successful `cert-show' command indicates that the CA is up and
running, but the error message indicates that the host running the
failing action cannot contact the CA.  You should check DNS and
firewall settings as a first step.

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

[Freeipa-users] Update NON-ipa Bind slave server from IPA-DNS edit/update

[Matt .]

Hi Guys,

What is the way to notify or update a Bind slave which is not an IPA server ?

Do I need to manuallu add an also-notify to the /etc/bind.conf on the
IPA master or is there a different way how to accomplish this ?

I hope this is possible and anyone can explain me how.

Thanks!

Matt

-- 
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 Error 4301: CertificateOperationError

[Z D]

Hello,
There is the error on ver 4.2 while viewing certs: "IPA Error 4301: 
CertificateOperationError", next it read " Certificate operation cannot be 
completed: Unable to communicate with CMS ([Errno 113] No route to host)".

I suspect you'll be asking for below two commands, here are results.

# ipa cert-show 1
  Certificate: MIIDlzCCAn+gAwIBAgIBATANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQKDA1VUy5P
..shortened ...
H6S7tS4pT9w77K8=
  Subject: CN=Certificate Authority,O=COMP.COM
  Issuer: CN=Certificate Authority,O=COMP.COM
  Not Before: Wed Aug 17 17:20:41 2016 UTC
  Not After: Sun Aug 17 17:20:41 2036 UTC
  Fingerprint (MD5): 00:a5:2c:2d:ea:c8:27:33:62:35:75:53:12:6a:0d:c1
  Fingerprint (SHA1): 
d1:58:78:83:31:b8:ad:ae:af:2c:e7:05:44:67:6e:3a:37:8c:00:1a
  Serial number (hex): 0x1
  Serial number: 1

# ipactl restart
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting named Service
Restarting ipa_memcached Service
Restarting httpd Service
Restarting ipa-otpd Service
Restarting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful

Any help is appreciated, thanks
Zarko

-- 
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] Unknown Error - error (pop-up) window

[Zarko Dudic]

Hi all,

IPA version: ipa-server-4.2.0-15.0.1.el7_2.18.x86_64
Kernel: 3.8.13-118.10.2.el7uek.x86_64

I start seeing pop-up window titled "Unknown Error" with message "error" 
and buttons Retry and Cancel. It happens when selecting almost anything 
on the Web interface, from Identity to IPA Server.
Certainly changes have been made, like adding identities, adding certs 
in nssdb, but can't think of anything that can cause such error.
And when errors happen, no new logs in /var/log/httpd both access and 
error logs. Also no new logs in /var/log/dirsrv/slapd-REALM/


For starter, can you please suggest any troubleshooting steps and other 
logs to query.


--
Thanks,
Zarko

--
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-cert-agent, Object Signing Cert certificate renewal

[Rob Crittenden]

realstarhealer wrote:

Hi,

It seemes I confused you. I just used the CVE Tutorial as a hint on
generally how to create a new Cert for ipa-ca-agent (for uid admin).
There is nothing wrong with my IPA RA (ipaCert), as it is monitored via
certmonger and has been renewed recently.

So returning to my previous question, is it sufficient to replace the
expired  #6 for uid admin in ldap with my new Cert, i created or is #6
used in more location than this one?


You'd also need to update the description value.

Why are you concerned about updating this certificate? IPA doesn't use 
it in any way AFAIK.


rob



Thanks and Greetings
Vitali


 Ursprüngliche Nachricht 
Von: Rob Crittenden 
Datum: 22.08.16 16:40 (GMT+01:00)
An: realstarhealer , Freeipa-users@redhat.com
Cc: Jan Cholasta 
Betreff: Re: AW: [Freeipa-users] ipa-cert-agent, Object Signing Cert
certificate renewal

Please keep responses on the list.

realstarhealer wrote:

Hi Rob,

setting back the date and restarting did not help, in fact it can't,
because certmonger is not tracking these two by default.

Regarding the ipa-ca-agent Cert:
I followed CVE-2015-5284 slightly to create a new valid ipa-ca-agent
certificate.


You re-created the wrong cert. You need the cert with subject 'CN=IPA
RA,O=' The RA agent (original serial # usually 7) and the CA
Agent (original serial # usually 6) have different purposes.

Were you affected by the CVE? I'm not sure why you'd try to replace it
in this way.

As for the tracking, you'd do something like this (untested b/c I don't
have a 4.1 install):

# getcert start-tracking -d /etc/httpd/alias -n ipaCert -p
/etc/httpd/alias/pwdfile.txt -c dogtag-ipa-ca-renew-agent -C renew_ra_cert


Via pki cert-find --name 'ipa-ca-agent' I can now see both, the new and
the expired.
Via freeipa webui I can also See both.
Via ldapsearch -D 'cn=Directory Manager' -W -b 'ou=people,o=ipaca' I see
uid=admin using the old expired Cert ID.

Is it sufficient to ldapmodify the new valid Cert to uid=admin to solve
this? As far as I can See,  it is the only place this Cert is used.


The instructions on the wiki at
https://www.freeipa.org/page/CVE-2015-5284 seem to confuse the RA agent
with the CA agent. I don't know the details of that CVE but someone
needs to revisit these docs. I'd prefer some clarity around SUBJECT, it
will always be CN=IPA RA,

Similarly there is no need to update ca-agent.p12 file if the RA agent
cert is being replaced.

rob



Greetings
Vitali


 Ursprüngliche Nachricht 
Von: Rob Crittenden 
Datum: 18.08.16 15:28 (GMT+01:00)
An: realstarhealer , freeipa-users@redhat.com
Betreff: Re: [Freeipa-users] ipa-cert-agent, Object Signing Cert
certificate renewal

realstarhealer wrote:

Hi,

I am in charge for a freeipa 4.1.0.18.el7 server with ldap backend and
noticed some expired certificates recently. Most of them but 2 are
auto-renewing by certmonger as I checked. All of them are self signed.

"CN=ipa-ca-agent" and "CN=Object Signing Cert" are not subscribed by
certmonger, ipa-ca-agent expired some days ago and has not been renewed.
Second one expires soon. No consequences noticed so far.
Can you tell me what they both are for and - if needed - how I should
renew that separately? Preferable with certmonger. An Output how the
tracking config should look like would be nice.


The object signing cert can probably be ignored. This was used to sign a
jar file used to automatically configure Firefox but that approach
doesn't work any more.

The agent cert is used by IPA to communicate to dogtag so yeah, that's
pretty important.

Since it is expired you'd need to go back in time to renew it.
Restarting the certmonger process is the simplest method to force it to
try to renew.

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] Very slow enrolment process

[Rob Crittenden]

Petr Spacek wrote:

On 22.8.2016 03:42, William Muriithi wrote:

Hello,

I have systems that were previously using openLDAP and plan to migrate
them to freeIPA.  I have a problem I have been struggling with since
Thursday.  The client take 10 to 15 minutes to finish the enrolment
process.

I can't find anything in the logs, have disabled nscd, the DNS and
hostname is set up write and nothing on the message logs point me to
the problem.  Have put se-linux to permissive and done all the basic
checks I can think of.

Its always stalling at this point. What usually happen after the end
of the log below?

---

2016-08-22T01:12:07Z INFO Synchronizing time with KDC...

2016-08-22T01:12:07Z DEBUG Search DNS for SRV record of
_ntp._udp.eng.example.com.

2016-08-22T01:12:07Z DEBUG DNS record found:
DNSResult::name:_ntp._udp.eng.example.com.,type:33,class:1,rdata={priority:0,port:123,weight:100,server:hydrogen.eng.example.com.}

2016-08-22T01:12:08Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v
hydrogen.eng.example.com

2016-08-22T01:12:08Z DEBUG stdout=

2016-08-22T01:12:08Z DEBUG stderr=

2016-08-22T01:12:08Z DEBUG Writing Kerberos configuration to /tmp/tmpYLpzuV:

2016-08-22T01:12:08Z DEBUG #File modified by ipa-client-install


includedir /var/lib/sss/pubconf/krb5.include.d/


[libdefaults]

   default_realm = ENG.EXAMPLE.COM

   dns_lookup_realm = false

   dns_lookup_kdc = false

   rdns = false

   ticket_lifetime = 24h

   forwardable = yes

   udp_preference_limit = 0



[realms]

   ENG.EXAMPLE.COM = {

 kdc = hydrogen.eng.example.com:88

 master_kdc = hydrogen.eng.example.com:88

 admin_server = hydrogen.eng.example.com:749

 default_domain = eng.example.com

 pkinit_anchors = FILE:/etc/ipa/ca.crt


   }



[domain_realm]

   .eng.example.com = ENG.EXAMPLE.COM

   eng.example.com = ENG.EXAMPLE.COM



This is interesting. This output is printed right before calling ipa-join
command so you should see follow-up line "Starting external process".

Is it somewhere in the file?

I cannot imagine where it could hang between write to the krb5.conf file and
starting ipa-join command...



It potentially does a kinit before calling ipa-join depending on the 
options passed in.


What I'd do is strace the install process. This should tell you what 
it's doing.


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] ipa-cert-agent, Object Signing Cert certificate renewal

[Rob Crittenden]

Please keep responses on the list.

realstarhealer wrote:

Hi Rob,

setting back the date and restarting did not help, in fact it can't,
because certmonger is not tracking these two by default.

Regarding the ipa-ca-agent Cert:
I followed CVE-2015-5284 slightly to create a new valid ipa-ca-agent
certificate.


You re-created the wrong cert. You need the cert with subject 'CN=IPA 
RA,O=' The RA agent (original serial # usually 7) and the CA 
Agent (original serial # usually 6) have different purposes.


Were you affected by the CVE? I'm not sure why you'd try to replace it 
in this way.


As for the tracking, you'd do something like this (untested b/c I don't 
have a 4.1 install):


# getcert start-tracking -d /etc/httpd/alias -n ipaCert -p 
/etc/httpd/alias/pwdfile.txt -c dogtag-ipa-ca-renew-agent -C renew_ra_cert



Via pki cert-find --name 'ipa-ca-agent' I can now see both, the new and
the expired.
Via freeipa webui I can also See both.
Via ldapsearch -D 'cn=Directory Manager' -W -b 'ou=people,o=ipaca' I see
uid=admin using the old expired Cert ID.

Is it sufficient to ldapmodify the new valid Cert to uid=admin to solve
this? As far as I can See,  it is the only place this Cert is used.


The instructions on the wiki at 
https://www.freeipa.org/page/CVE-2015-5284 seem to confuse the RA agent 
with the CA agent. I don't know the details of that CVE but someone 
needs to revisit these docs. I'd prefer some clarity around SUBJECT, it 
will always be CN=IPA RA,


Similarly there is no need to update ca-agent.p12 file if the RA agent 
cert is being replaced.


rob



Greetings
Vitali


 Ursprüngliche Nachricht 
Von: Rob Crittenden 
Datum: 18.08.16 15:28 (GMT+01:00)
An: realstarhealer , freeipa-users@redhat.com
Betreff: Re: [Freeipa-users] ipa-cert-agent, Object Signing Cert
certificate renewal

realstarhealer wrote:

Hi,

I am in charge for a freeipa 4.1.0.18.el7 server with ldap backend and
noticed some expired certificates recently. Most of them but 2 are
auto-renewing by certmonger as I checked. All of them are self signed.

"CN=ipa-ca-agent" and "CN=Object Signing Cert" are not subscribed by
certmonger, ipa-ca-agent expired some days ago and has not been renewed.
Second one expires soon. No consequences noticed so far.
Can you tell me what they both are for and - if needed - how I should
renew that separately? Preferable with certmonger. An Output how the
tracking config should look like would be nice.


The object signing cert can probably be ignored. This was used to sign a
jar file used to automatically configure Firefox but that approach
doesn't work any more.

The agent cert is used by IPA to communicate to dogtag so yeah, that's
pretty important.

Since it is expired you'd need to go back in time to renew it.
Restarting the certmonger process is the simplest method to force it to
try to renew.

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] replica_generate_next_csn messages in dirsrv error logs

[John Desantis]

Ludwig,

> I looked into the logs, I think the messages are harmless, just an effect of
> csn adjustment due to time difference on the two machines. I had said that
> the replication protocol will try to adjust the csn generator, but looks
> like you have long lasting replication connections and the adjustment is
> done only at the beginning. Maybe we can look into this and improve it.
> Just the tracking of one of these error messages:

Thank you for your insight and looking into these logs.  Given the
relative obscurity of results of this message within Google and this
mailing list, there may be nothing to improve!  In other words, it
looks like the issue has been resolved.

In a not so nutshell, I've been monitoring a ns-slapd thread that was
continually pegged with high file I/O via the 'pread' while reading
its db* files on the master server, which produced some latency.
After seemingly pointless searches, I stumbled upon Rich's "dbmon.sh"
via a post [1] and verified that some tuning was needed for our site.
After applying the changes I did notice that there was a drop in
memory pressure on the system and that there seemed to be less
latency, but the ns-slapd thread was still performing a lot of file
I/O.  It seems now that the issue with the timing was due to this
observed latency.  Anyways, I was still bugged with an issue I had
originally opened in my first post to the list [2] and finally
discovered that one of our replication nodes was culpable for not
responding to the 'ipa-replica-manage clean-ruv #' (stdout via this
command did not report which servers had and had not properly cleaned
the RUV).  I was able to manually remove it via 'ldapmodify' and
cleanruv.  At this point, some of the file I/O I had seen was more
than halved.  The last piece of the puzzle was using
"ipa-csreplica-manage" and 'ldapmodify' to remove [3] the CA
references to the replica mentioned in [1].  Once this was done, all
of the thread I/O stopped.

I then performed some testing of adding and removing DNS records via a
for loop, with and without sleep statements.  Not once did any more of
the replica_generate_next_csn messages appear.

For anyone else seeing similar issues, hopefully this information will help.

John DeSantis

[1] https://www.redhat.com/archives/freeipa-users/2014-November/msg00138.html
[2] https://www.redhat.com/archives/freeipa-users/2014-October/msg00283.html
[3] https://www.redhat.com/archives/freeipa-users/2015-March/msg00436.html

2016-08-22 5:41 GMT-04:00 Ludwig Krispenz :
> Thanks,
>
> I looked into the logs, I think the messages are harmless, just an effect of
> csn adjustment due to time difference on the two machines. I had said that
> the replication protocol will try to adjust the csn generator, but looks
> like you have long lasting replication connections and the adjustment is
> done only at the beginning. Maybe we can look into this and improve it.
> Just the tracking of one of these error messages:
>
> the entry is modified on adm3
> adm3 :[19/Aug/2016:15:47:05 -0400] conn=13 op=126637 MOD
> dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
> adm3 :[19/Aug/2016:15:47:05 -0400] conn=13 op=126637 RESULT err=0 tag=103
> nentries=0 etime=0 csn=57b763030016
> this mod is replicated to adm0
> adm0 :[19/Aug/2016:15:47:06 -0400] conn=1395 op=86121 MOD
> dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
> adm0 :[19/Aug/2016:15:47:06 -0400] conn=1395 op=86121 RESULT err=0 tag=103
> nentries=0 etime=0 csn=57b763030016
> the entry is modified again on adm0
> adm0 :[19/Aug/2016:15:47:07 -0400] conn=27 op=1108697 MOD
> dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
> but it looks like the csn generated is smaller than the one already in the
> entry, and it is adjusted
> adm0 :[19/Aug/2016:15:47:07 -0400] - replica_generate_next_csn:
> opcsn=57b76301000a0004 <= basecsn=57b763030016, adjusted
> opcsn=57b7630300010004
> then the result is logged with the adjusted csn
> adm0 :[19/Aug/2016:15:47:07 -0400] conn=27 op=1108697 RESULT err=0 tag=103
> nentries=0 etime=0 csn=57b7630300010004
>
> so the mechanism works, but the messages may be confusing and improvement of
> the protocol could be investigated.
>
> One question I have, but someone more familiar with dns should answer:
> we  have regular updates of the same entry on both replicas, about every 2
> seconds, what is the reason for this ?
>
>
> /tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:03 -0400] conn=13
> op=126630 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
> /tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:05 -0400] conn=13
> op=126637 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
> /tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:07 -0400] conn=13
> op=126646 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
> /tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:09 -0400] conn=13
> op=126653 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"

Re: [Freeipa-users] replica_generate_next_csn messages in dirsrv error logs

[Ludwig Krispenz]

Thanks,

I looked into the logs, I think the messages are harmless, just an 
effect of csn adjustment due to time difference on the two machines. I 
had said that the replication protocol will try to adjust the csn 
generator, but looks like you have long lasting replication connections 
and the adjustment is done only at the beginning. Maybe we can look into 
this and improve it.

Just the tracking of one of these error messages:

the entry is modified on adm3
adm3 :[19/Aug/2016:15:47:05 -0400] conn=13 op=126637 MOD 
dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
adm3 :[19/Aug/2016:15:47:05 -0400] conn=13 op=126637 RESULT err=0 
tag=103 nentries=0 etime=0 csn=57b763030016

this mod is replicated to adm0
adm0 :[19/Aug/2016:15:47:06 -0400] conn=1395 op=86121 MOD 
dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
adm0 :[19/Aug/2016:15:47:06 -0400] conn=1395 op=86121 RESULT err=0 
tag=103 nentries=0 etime=0 csn=57b763030016

the entry is modified again on adm0
adm0 :[19/Aug/2016:15:47:07 -0400] conn=27 op=1108697 MOD 
dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
but it looks like the csn generated is smaller than the one already in 
the entry, and it is adjusted
adm0 :[19/Aug/2016:15:47:07 -0400] - replica_generate_next_csn: 
opcsn=57b76301000a0004 <= basecsn=57b763030016, adjusted 
opcsn=57b7630300010004

then the result is logged with the adjusted csn
adm0 :[19/Aug/2016:15:47:07 -0400] conn=27 op=1108697 RESULT err=0 
tag=103 nentries=0 etime=0 csn=57b7630300010004


so the mechanism works, but the messages may be confusing and 
improvement of the protocol could be investigated.


One question I have, but someone more familiar with dns should answer:
we  have regular updates of the same entry on both replicas, about every 
2 seconds, what is the reason for this ?



/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:03 -0400] conn=13 
op=126630 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:05 -0400] conn=13 
op=126637 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:07 -0400] conn=13 
op=126646 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:09 -0400] conn=13 
op=126653 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:13 -0400] conn=13 
op=12 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:16 -0400] conn=13 
op=126673 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:18 -0400] conn=13 
op=126689 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:20 -0400] conn=13 
op=126696 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:21 -0400] conn=13 
op=126702 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:23 -0400] conn=13 
op=126737 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:26 -0400] conn=13 
op=126758 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"
/tmp/adm3-logs-del39-errors.txt:[19/Aug/2016:15:47:29 -0400] conn=13 
op=126801 MOD dn="idnsname=rc.usf.edu,cn=dns,dc=rc,dc=usf,dc=edu"




On 08/19/2016 10:00 PM, John Desantis wrote:

Ludwig,


you still only grep the replication connection, but before being replicated
the entry has to be added by some client connection, can you get all
references to the entry ?
the log snippet you provide shows also csns with tag=103, which indicate a
MOD, are these MODs for the added entries ? or other mods ?

.

I can't believe I did that!

Ok, so the logs have been rotated (I didn't think to adjust
logrotate..), so there aren't any logs to peruse for the case I've
presented so far.  However, I was able to reproduce the errors by
"bulk" deleting 39 DNS entries, and only the MASTER reported
"replica_generate_next_csn" entries.

Given the size of the logs, I think it would be pointless to do any
kind of sanitization.  I'll go ahead and gzip them for you and email
you off-list.

I've labeled them as MASTER and REPLICA.

John DeSantis


2016-08-19 9:18 GMT-04:00 Ludwig Krispenz :

On 08/18/2016 05:28 PM, John Desantis wrote:

Ludwig,


unfortunately this is not enough to determine what is going on. The
intersting generated/used csn is only logged in the
corresponding RESULT message and these are only the replication
connections,
it would be necessary to see the
original ADD operation, was it added once or twice by a client ?
you could pick one entry eg server-6-3-sp and grep for all references in
the
access logs of both servers  (maybe there are mods as well) and then
get also get the RESULT line for the ops found

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

[Petr Spacek]

On 19.8.2016 19:32, Rakesh Rajasekharan wrote:
> I am running my set up on AWS cloud, and entropy is low at around 180 .
> 
> I plan to increase it bu installing haveged . But, would low entropy by any
> chance cause this issue of intermittent hang .
> Also, the hang is mostly observed when registering around 20 clients
> together

Possibly, I'm not sure. If you want to dig into this, I would do this:
1. look what process hangs on client (using pstree command or so)
$ pstree

2. look to what server and port is the hanging client connected to
$ lsof -p 

3. jump to server and see what process is bound to the target port
$ netstat -pn

4. see where the process if hanging
$ strace -p 

I hope it helps.

Petr^2 Spacek

> On Fri, Aug 19, 2016 at 7:24 PM, Rakesh Rajasekharan <
> rakesh.rajasekha...@gmail.com> wrote:
> 
>> yes there seems to be something thats worrying.. I have faced this today
>> as well.
>> There are few hosts around 280 odd left and when i try adding them to IPA
>> , the slowness begins..
>>
>> all the ipa commands like ipa user-find.. etc becomes very slow in
>> responding.
>>
>> the SYNC_RECV are not many though just around 80-90 and today that was
>> around 20 only
>>
>>
>> I have for now increased tcp_max_syn_backlog to 5000.
>> For now the slowness seems to have gone.. but I will do a try adding the
>> clients again tomorrow and see how it goes
>>
>> Thanks
>> Rakesh
>>
>> The issues
>>
>> On Fri, Aug 19, 2016 at 12:58 PM, Petr Spacek  wrote:
>>
>>> On 18.8.2016 17:23, Rakesh Rajasekharan wrote:
 Hi

 I am migrating to freeipa from openldap and have around 4000 clients

 I had openned a another thread on that, but chose to start a new one
>>> here
 as its a separate issue

 I was able to change the nssslapd-maxdescriptors adding an ldif file

 cat nsslapd-modify.ldif
 dn: cn=config
 changetype: modify
 replace: nsslapd-maxdescriptors
 nsslapd-maxdescriptors: 17000

 and running the ldapmodify command

 I have now started moving clients running an openldap to Freeipa and
>>> have
 today moved close to 2000 clients

 However, I have noticed that IPA hangs intermittently.

 running a kinit admin returns the below error
 kinit: Generic error (see e-text) while getting initial credentials

 from the /var/log/messages, I see this entry

  prod-ipa-master-int kernel: [104090.315801] TCP: request_sock_TCP:
 Possible SYN flooding on port 88. Sending cookies.  Check SNMP counters.
>>>
>>> I would be worried about this message. Maybe kernel/firewall is doing
>>> something fishy behind your back and blocking some connections or so.
>>>
>>> Petr^2 Spacek
>>>
>>>
 Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Started Session 4885 of
 user root.
 Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Starting Session 4885 of
 user root.
 Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Started Session 4886 of
 user root.
 Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Starting Session 4886 of
 user root.
 Aug 18 13:02:40 prod-ipa-master-int python[28984]: ansible-command
>>> Invoked
 with creates=None executable=None shell=True args= removes=None
>>> warn=True
 chdir=None
 Aug 18 13:04:37 prod-ipa-master-int sssd_be: GSSAPI Error: Unspecified
>>> GSS
 failure.  Minor code may provide more information (KDC returned error
 string: PROCESS_TGS)

 Could it be possible that its due to the initial load of adding the
>>> clients
 or is there something else that I need to take care of.

-- 
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] Unable to set up freeIPA on a fresh ubuntu 16.04.1 install

[Alexander Bokovoy]

On Fri, 19 Aug 2016, David Kowis wrote:

On 08/16/2016 10:51 PM, Alexander Bokovoy wrote:

On Tue, 16 Aug 2016, David Kowis wrote:

On 08/15/2016 09:27 PM, David Kowis wrote:

On 08/15/2016 08:05 PM, Rob Crittenden wrote:

David Kowis wrote:

On 08/15/2016 04:33 AM, Petr Spacek wrote:

This is weird as LDAP SASL & GSSAPI is pretty standard thing.

In any case, you can check server logs or use tcpdump/wireshark and
see if the
error somes from LDAP server or if it is client side error.

That would tell us where to focus.


I think I know what's going on, but not why it's going on:

https://bugs.launchpad.net/ubuntu/+source/389-ds-base/+bug/1088822
This bug lead me to wonder where the directory server was finding it's
GSSAPI modules.

For some reason dirsrv is looking in /usr/lib/sasl2 for it's sasl
modules, when they're actually installed in /usr/lib/i386-linux-gnu/sasl2

A symlink:
ln -s /usr/lib/i386-linux-gnu/sasl2 /usr/lib/sasl2


and then suddenly:
ldapsearch -h localhost -p 389 -x -b "" -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: SCRAM-SHA-1
supportedSASLMechanisms: GS2-IAKERB
supportedSASLMechanisms: GS2-KRB5
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: ANONYMOUS

Should I file a new bug with ubuntu? Did I find some weird i386 only bug
that should've been fixed?

Please file a bug against CyrusSASL in Ubuntu because it is library's
duty to handle own modules -- while it provides sasl_set_path() to
application to define where to load modules from, the defaults should be
set reasonably. 389-ds does not use sasl_set_path().


--
/ 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] Unable to set up freeIPA on a fresh ubuntu 16.04.1 install

[David Kowis]

On 08/16/2016 10:51 PM, Alexander Bokovoy wrote:
> On Tue, 16 Aug 2016, David Kowis wrote:
>> On 08/15/2016 09:27 PM, David Kowis wrote:
>>> On 08/15/2016 08:05 PM, Rob Crittenden wrote:
 David Kowis wrote:
> On 08/15/2016 04:33 AM, Petr Spacek wrote:
>> This is weird as LDAP SASL & GSSAPI is pretty standard thing.
>>
>> In any case, you can check server logs or use tcpdump/wireshark and
>> see if the
>> error somes from LDAP server or if it is client side error.
>>
>> That would tell us where to focus.

I think I know what's going on, but not why it's going on:

https://bugs.launchpad.net/ubuntu/+source/389-ds-base/+bug/1088822
This bug lead me to wonder where the directory server was finding it's
GSSAPI modules.

For some reason dirsrv is looking in /usr/lib/sasl2 for it's sasl
modules, when they're actually installed in /usr/lib/i386-linux-gnu/sasl2

A symlink:
ln -s /usr/lib/i386-linux-gnu/sasl2 /usr/lib/sasl2


and then suddenly:
ldapsearch -h localhost -p 389 -x -b "" -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: SCRAM-SHA-1
supportedSASLMechanisms: GS2-IAKERB
supportedSASLMechanisms: GS2-KRB5
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: ANONYMOUS

Should I file a new bug with ubuntu? Did I find some weird i386 only bug
that should've been fixed?

Thanks,
David Kowis

PS: sorry if this is a repost, I sent it before, but it doesn't seem to
be showing up on the list...

>>
>
> Welp, I've got a pile of logs for you:
> https://gist.github.com/dkowis/a82d4ec6b1823d9e1b95ffcc94666ae0
>
> The last few lines are probably the relevant ones.
>
> [15/Aug/2016:18:12:53 -0500] conn=1307 op=0 BIND dn="" method=sasl
> version=3 mech=GSSAPI
> [15/Aug/2016:18:12:53 -0500] conn=1307 op=0 RESULT err=7 tag=97
> nentries=0 etime=0
> [15/Aug/2016:18:12:54 -0500] conn=1307 op=1 UNBIND
> [15/Aug/2016:18:12:54 -0500] conn=1307 op=1 fd=68 closed - U1
>
>
> Something tries to bind with no dn, and then fails I think?

 No this is typical logging for GSSAPI (minus the error).

 The error code is LDAP_AUTH_METHOD_NOT_SUPPORTED. Do you have the cyrus
 SASL GSSAPI package installed? In Fedora the package is
 cyrus-sasl-gssapi.

>>
>> Still trying to figure stuff out:
>>
>> root@freeipavm:/var/log/dirsrv/slapd-DARK-KOW-IS# ldapsearch -h
>> localhost -p 389 -x -b "" -s base -LLL SupportedSASLMechanisms
>> dn:
>> SupportedSASLMechanisms: EXTERNAL
>>
>>
>> Should I have more than just EXTERNAL when this happens? How do I debug
>> more about what SASL authentication stuff should be there? I'm having a
>> great deal of difficulty finding documentation for the 389 directory
>> server's SASL configuration. *If* that's even the place I should be
>> looking. How can I narrow this down more?
> 389-ds does dynamically include all supported SASL mechanisms returned
> by CyrusSASL library. If you only get EXTERNAL, it means NO mechanisms
> were returned by your system SASL library. The attribute
> SupportedSASLMechanisms you see in the rootdse query above is read-only:
> it only shows which SASL mechanisms 389-ds knows about but you cannot
> influence them via this attribute. You need to look at your CyrusSASL
> library system configuration.
>
> What does 'pluginviewer' output show? Here is what Fedora 24 reports
> when following packages are installed:
> cyrus-sasl-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-md5-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-plain-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-gssapi-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64
>
> # pluginviewer Installed and properly configured auxprop mechanisms are:
> sasldb
> List of auxprop plugins follows
> Plugin "sasldb" , API version: 8
> supports store: yes
>
> Installed and properly configured SASL (server side) mechanisms are:
>  GSS-SPNEGO GSSAPI DIGEST-MD5 EXTERNAL CRAM-MD5 LOGIN PLAIN ANONYMOUS
> Available SASL (server side) mechanisms matching your criteria are:
>  GSS-SPNEGO GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN ANONYMOUS
> List of server plugins follows
> Plugin "gssapiv2" [loaded], API version: 4
> SASL mechanism: GSS-SPNEGO, best SSF: 56, supports setpass: no
> security flags:
> NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH
> features:
> WANT_CLIENT_FIRST|PROXY_AUTHENTICATION|DONTUSE_USERPASSWD|SUPPORTS_HTTP
> Plugin "gssapiv2" [loaded], API version: 4
> SASL mechanism: GSSAPI, best SSF: 56, supports setpass: no
> security flags:
> NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH
> features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION|DONTUSE_USERPASSWD
> Plugin "digestmd5" [loaded], API version: 4
>  

Re: [Freeipa-users] Very slow enrolment process

[Petr Spacek]

On 22.8.2016 03:42, William Muriithi wrote:
> Hello,
> 
> I have systems that were previously using openLDAP and plan to migrate
> them to freeIPA.  I have a problem I have been struggling with since
> Thursday.  The client take 10 to 15 minutes to finish the enrolment
> process.
> 
> I can't find anything in the logs, have disabled nscd, the DNS and
> hostname is set up write and nothing on the message logs point me to
> the problem.  Have put se-linux to permissive and done all the basic
> checks I can think of.
> 
> Its always stalling at this point. What usually happen after the end
> of the log below?
> 
> ---
> 
> 2016-08-22T01:12:07Z INFO Synchronizing time with KDC...
> 
> 2016-08-22T01:12:07Z DEBUG Search DNS for SRV record of
> _ntp._udp.eng.example.com.
> 
> 2016-08-22T01:12:07Z DEBUG DNS record found:
> DNSResult::name:_ntp._udp.eng.example.com.,type:33,class:1,rdata={priority:0,port:123,weight:100,server:hydrogen.eng.example.com.}
> 
> 2016-08-22T01:12:08Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v
> hydrogen.eng.example.com
> 
> 2016-08-22T01:12:08Z DEBUG stdout=
> 
> 2016-08-22T01:12:08Z DEBUG stderr=
> 
> 2016-08-22T01:12:08Z DEBUG Writing Kerberos configuration to /tmp/tmpYLpzuV:
> 
> 2016-08-22T01:12:08Z DEBUG #File modified by ipa-client-install
> 
> 
> includedir /var/lib/sss/pubconf/krb5.include.d/
> 
> 
> [libdefaults]
> 
>   default_realm = ENG.EXAMPLE.COM
> 
>   dns_lookup_realm = false
> 
>   dns_lookup_kdc = false
> 
>   rdns = false
> 
>   ticket_lifetime = 24h
> 
>   forwardable = yes
> 
>   udp_preference_limit = 0
> 
> 
> 
> [realms]
> 
>   ENG.EXAMPLE.COM = {
> 
> kdc = hydrogen.eng.example.com:88
> 
> master_kdc = hydrogen.eng.example.com:88
> 
> admin_server = hydrogen.eng.example.com:749
> 
> default_domain = eng.example.com
> 
> pkinit_anchors = FILE:/etc/ipa/ca.crt
> 
> 
>   }
> 
> 
> 
> [domain_realm]
> 
>   .eng.example.com = ENG.EXAMPLE.COM
> 
>   eng.example.com = ENG.EXAMPLE.COM


This is interesting. This output is printed right before calling ipa-join
command so you should see follow-up line "Starting external process".

Is it somewhere in the file?

I cannot imagine where it could hang between write to the krb5.conf file and
starting ipa-join command...

-- 
Petr^2 Spacek

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