Re: [Freeipa-users] ipa-replica-prepare error: Profile caIPAserviceCert Not Found

2015-12-21 Thread Fraser Tweedale
On Mon, Dec 21, 2015 at 01:57:02PM +0100, Karl Forner wrote:
> Hello,
> 
> Running:
> ipa-replica-prepare ipa-h3s1.example.com --ip-address xx.xx.xx.xx -d -v
> fails
> with
> ipa: DEBUG: Protocol: TLS1.2
> ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA
> ipa: DEBUG: request status 200
> ipa: DEBUG: request reason_phrase u'OK'
> ipa: DEBUG: request headers {'date': 'Mon, 21 Dec 2015 12:50:59 GMT',
> 'content-length': '148', 'content-type': 'application/xml', 'server':
> 'Apache-Coyote/1.1'}
> ipa: DEBUG: request body ' standalone="no"?>1Profile
> caIPAserviceCert Not Found'
> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:   File
> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
> execute
> 
> The context is probably unusual:
> I run the command on a replica with CA from a server in freeipa v4.1.4 (in
> a adelton/freeipa-server docker)
> which is a freeipa v4.2.3  running in
> adelton/freeipa-server:lastest-systemd docker
> 
> I found this ticket which looks similar:
> https://fedorahosted.org/freeipa/ticket/5376
> 
> Is there something wrong with my replica knowing that it has been
> replicated from a 4.1.4 ?
> Is there a work-around ?
> 
> Thanks
> Karl

Hi Karl,

I have a patch for Dogtag that I think will fix this issue.  Would
you be willing to test it?  If so, which version of Fedora/RHEL are
you using and I will prepare a build.

Regards,
Fraser

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

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


Re: [Freeipa-users] NetworkError : invalid continuation byte with utf8 codec

2015-12-21 Thread Fraser Tweedale
On Mon, Dec 21, 2015 at 05:29:01PM +0100, Gmail wrote:
> Hi all,
> 
> When trying to install on a fresh new Centos 7 I’ve got this error :
> 
> 2015-12-21T16:04:44Z DEBUG The ipa-server-install command failed, exception: 
> NetworkError: cannot connect to 
> 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't 
> decode byte 0xea in position 13: invalid continuation byte
> 2015-12-21T16:04:44Z ERROR cannot connect to 
> 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't 
> decode byte 0xea in position 13: invalid continuation byte
> 
> My freeipa-server version is :  4.2.0
> I’m running a Centos 3.10.0-327.3.1.el7.x86_64
> 
> Any idea of what goes wrong?
> 
Thanks for reporting.  I have not seen this error before.  Could you
please include the following log files and I will take a closer
look:

/var/log/ipaserver-install.log
/var/log/pki/pki-tomcat/ca/debug

Cheers,
Fraser

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

[Freeipa-users] Issues with 'A replication agreement for the host already exists', when it very much doesn't

2015-12-21 Thread Alex Williams
I began installing a new ipa4 replica this morning and it all went 
wrong. The ipa-replica-install script got all the way to restarting ipa 
with systemctl at the very end, having set up replication and then fell 
over, because systemctl couldn't find the ipa service. I removed the 
replica from our master, I deleted the host from there too, I 
un-installed ipa-server on the new replica machine, I even created a new 
replica-prepare script on the master, but now the server just errors 
immediately with:


A replication agreement for this host already exists. It needs to 
be removed.


I've verified several times, that no replica, or host with the same name 
exists in the master, there are no ldap entries under masters, with that 
hostname, nothing. There is literally no trace of the new host, on the 
old master. Running `ipa-replica-manage list` shows just the 3 ipa 
servers we have already, no sign of this new host. Yet, if I run 
`ipa-replica-manage del hostname --force` on the master, it will in fact 
say that it's forcing removal, skipping checking if anything will be 
orphaned and that no RUV records were found.


I'm now lost, I really don't know where to start with fixing this.

Not sure if this is relevant or not, but I'd rather bring it up and it 
not be, than not mention it and it turn out to be the reason. Our yum 
mirror is unfortunately now holding rhel7.2 packages, whilst our 
servers, are still on rhel7.1, which means our existing IPA servers, are 
ipa4.1 and the new one I tried to install, was ipa4.2, but on a rhel7.1 
box. I had previously attributed the failed systemctl command, to the 
fact that I was trying to run ipa4.2 on a rhel7.1 box, as I'm told there 
were a lot of modifications to systemctl in rhel7.2, but I need to fix 
this replication agreement issue, before I can try again with the box 
upgraded to rhel7.2.


Any ideas?

Cheers

Alex

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


[Freeipa-users] Using 3rd party certificates for HTTP/LDAP

2015-12-21 Thread Peter Pakos

Hi,

I tried to install a wildcard SSL certificate for HTTP/LDAP in our 
FreeIPA 4.1 (Centos 7.1) installation by following instructions from 
wiki page at 
http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP:


# ipa-server-certinstall -w -d shdc01.ipa.wandisco.com.pem
Directory Manager password:
Enter private key unlock password:
Command /usr/bin/certutil' '-d' '/etc/httpd/alias' '-D' '-n' 
'Server-Cert returned non-zero exit status 255


After this I was unable to start httpd service, error_log revealed the 
following error messages:


[Wed Nov 25 18:15:44.262751 2015] [:error] [pid 22124] Certificate not 
found: 'Server-Cert'


In order to resurrect the service I had to change NSSNickname in 
/etc/httpd/conf.d/nss.conf to match the new certificate's nickname.


Although the httpd service started, I couldn't get into Authentication 
tab in FreeIPA UI - I kept getting the following error message: "Unable 
to communicate with CMS (Service Unavailable)".


[root@shdc01 ~]# yum list installed | grep ipa-server
ipa-server.x86_64 4.1.0-18.el7.centos.4 @updates

[root@shdc01 ~]# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)

At this point I was forced to restore our FreeIPA installation from a 
snapshot as I wasn't able to fix it (I got some useful hints from 
#freeipa Freenode channel however we still didn't manage to fully 
resurrect the server).


My question is, what is the correct way of installing a 3rd party 
certificate for HTTP/LDAP that will actually work?


Many thanks in advance.

BTW, I also added a comment describing this problem to the ticket at 
https://fedorahosted.org/freeipa/ticket/5496.


--
Kind regards,
 Peter Pakos

--
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] Want faster user-add

2015-12-21 Thread Daryl Fonseca-Holt

Hi all,

Environment: RHEL6 with IPA 3.0 at current RedHat level. 64-core 256-GB 
RAM Oracle x4470 M2.


During our migration from NIS on Solaris 140,000+ accounts will be 
added. After tuning per the guides dbmon.sh shows no roevicts and we get 
high cache hit ratios.


Per a previous discussion with the list the input is broken down into 
batches of less than 1,000 users and the default IPA group is changed 
before each batch. This helped greatly.


Adding all the users takes many hours. Initially ipa user-add takes an 
average 2.3 seconds per user but degrades by the time there are 140,000 
users to an average 6.7 seconds per user.


In tracing it appears that a significant portion of the time ipa 
user-add takes is not the add itself, it is the query at the end that 
displays the resulting user account. Is there any legit way to prevent 
this query?


The length of time it takes to migrate is not a big concern. The concern 
is the start of the fall school term when we typically add approximately 
1,300 accounts per hour during the registration period with our current 
system.


All suggestions will be appreciated.

Regards, Daryl

--
 --
 Daryl Fonseca-Holt
 IST/CNS/Unix Server Team
 University of Manitoba
 204.480.1079

--
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] OS X Yosemite unable to authenticate

2015-12-21 Thread Nicola Canepa
I had to configure /etc/krb5.conf, and to avoid the requested reboot, I 
did a "dscacheutil -flushcache", both as the logged in user and as root.
I tried enabling the anonymous bind and now also the directory browser 
(and all the login process) works as expected.


Nicola

Il 21/12/15 17:39, Cal Sawyer ha scritto:

Thanks, John and Nicola

Kerberos occurred to me as well late in the day yesterday. Happily 
(?), knit works fine simply specifying the user in question with no 
need to suffix with the kerberos realm


I did find that my test user had an expired password, which i fixed on 
the IPA server.  This was never flagged up under Linux, btw.  It has 
not change anything, however, other than not prompting for password 
changes that never take effect.  Funnily, it expired in the midst of 
testing - fun.


I was mistaken when i said i was unable to log in - it turns out that 
it takes almost 10 minutes for a login from the frintend to complete - 
i just didn't wait long enough.  10 mins is of course unacceptable :)  
"su - user" and "login user" fail outright after rejecting accept any 
user's password


DNS is fine and i can resolve ldap and kerberos SRV records from the Mac

In line with Nicola's experience, i can browse groups and users in the 
Directory Editor and all attributes appear spot on.


Besides modding /etc/pam.d/authorization, adding a corrected 
edu.mit.kerberos to /LibraryPreferences and setting up the directory 
per linsec.ca, can anyone think of something i may have missed?  It's 
a real shame that the documentation on this stops around 5 years ago.


IPA devs: is there anything i should be on the lookout for in the 
dirsrv or krb5 logs on the IPA master?  I've disabled the secondary to 
prevent replication from clouding the log events


thanks, everyone
Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575 |www.blue-bolt.com

On 21/12/15 07:57, Nicola Canepa wrote:
Hello, I tried 2 weeks ago from Mavericks (OSX 10.9), but I had the 
opposite problem: kinit works fine, while I'm unable to see users 
with Directory Admin ((it always says it cant' connect, either with 
or without SSL)

I disabled anonymous searches in 389-ds, by the way.

Nicola

Il 21/12/15 07:50, John Obaterspok ha scritto:

Hi Cal,

Does a kinit work from a terminal? Does it work if you use "kinit 
user" or just if you use "kinit user@REALM.suffix"


-- john


2015-12-20 15:09 GMT+01:00 Cal Sawyer >:


Hi, all

I'm attempting to set up LDAP auth (against IPA server 4.10)
from a OSX 10.10.5 (Yosemite) client

Using the excellent instructions at

http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server,
I've populated the specified files, d/l'd the cert, am able to
configure Users and Groups objects/attribs and browse both from
within OSX's Directory Utility. ldapsearch similarly returns the
expected results.

In spite of this, i'm unable to authenticate as any IPA-LDAP
user on this system

dirsrv log on the ipa master shows no apparent errors - remote
auth attempts exit with "RESULT err=0 tag=101 nentries=1
etime=0", but tell the truth, there so much stuff there and
being rather inexperienced with LDAP diags i might easily be
missing something in the details

The linsec.ca  instructions were written in
the 10.7-10.8 era so something may have changed since.  Having
said that, we've had no problems authenticating against our
existing OpenLDAP server (which IPA is slated to replace) right
up to 10.10.5 with no zero to our Directory Utility setup.

Hoping someone here has some contemporary experience with OSX
and IPA and for whom this issue rings a bell?

many thanks

Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575  |
www.blue-bolt.com 


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






--

Nicola Canepa
Tel: +39-0522-399-3474
canep...@mmfg.it
---
Il contenuto della presente comunicazione è riservato e destinato 
esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona 
diversa dal destinatario sono proibite la diffusione, la distribuzione e la 
copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e 
di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati 
contenuti. La presente comunicazione (comprensiva dei documenti allegati) non 
avrà valore di proposta contrattuale e/o accettazione di proposte provenienti 
dal destinatario, nè rinuncia o riconoscimento di diritti, debiti e/o crediti, 
nè sarà impegnativa, qualora non sia so

Re: [Freeipa-users] unable to effectively delete a replica agreement

2015-12-21 Thread Karl Forner
It's quite a problem for me.
Would upgrading to a more recent version solve the problem ?

How does freeIPA knows that a host is a freeIPA host ? From the LDAP ?

Thanks

On Fri, Dec 18, 2015 at 3:45 PM, Karl Forner  wrote:

> I am running a master freeIPA called "ipa" in an adelton/freeipa-server
> (freeIPA 4.1.4).
> I am able to create a replica server "ipa2", still in an
> adelton/freeipa-server.
>
> If I stop my ipa2 replica, and try to delete the replication agreement:
>
> %ipa-replica-manage del ipa2.example.com --force  -v
>
> It hangs forever.
> If I run it using the --cleanup option, it seems to work.
>
> But when I try to run again from scratch my replica, using the same name,
> I get:
>
> Checking forwarders, please wait ...
> WARNING: DNS forwarder 10.9.70.7 does not return DNSSEC signatures in
> answers
> Please fix forwarder configuration to enable DNSSEC support.
> (For BIND 9 add directive "dnssec-enable yes;" to "options {}")
> WARNING: DNSSEC validation will be disabled
> Warning: skipping DNS resolution of host ipa2.example.com
> Warning: skipping DNS resolution of host ipa.example.com
> Using reverse zone(s) 0.17.172.in-addr.arpa.
> A replication agreement for this host already exists. It needs to be
> removed.
> Run this on the master that generated the info file:
> % ipa-replica-manage del ipa2.example.com --force
>
> On my master:
> # ipa-replica-manage list
> ipas.example.com: master
> ipa.example.com: master
>
> I manually removed all DNS entries from the 3 zones mentioning ipa2. I can
> check in the web UI, using the search feature that ipa2 has no occurrence.
>
> So I do not understand why the replica install thinks there's still a
> replication agreement.
> And I'd like to know:
> 1) why this command did not work
>
> ipa-replica-manage del ipa2.example.com --force  -v
>
>
> 2) How could I manually effectively delete this agrrement left-over.
>
>
> Thanks.
> Karl
>
>
-- 
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] OS X Yosemite unable to authenticate

2015-12-21 Thread Cal Sawyer

Thanks, John and Nicola

Kerberos occurred to me as well late in the day yesterday.  Happily (?), 
knit works fine simply specifying the user in question with no need to 
suffix with the kerberos realm


I did find that my test user had an expired password, which i fixed on 
the IPA server.  This was never flagged up under Linux, btw.  It has not 
change anything, however, other than not prompting for password changes 
that never take effect.  Funnily, it expired in the midst of testing - fun.


I was mistaken when i said i was unable to log in - it turns out that it 
takes almost 10 minutes for a login from the frintend to complete - i 
just didn't wait long enough.  10 mins is of course unacceptable :)  "su 
- user" and "login user" fail outright after rejecting accept any user's 
password


DNS is fine and i can resolve ldap and kerberos SRV records from the Mac

In line with Nicola's experience, i can browse groups and users in the 
Directory Editor and all attributes appear spot on.


Besides modding /etc/pam.d/authorization, adding a corrected 
edu.mit.kerberos to /LibraryPreferences and setting up the directory per 
linsec.ca, can anyone think of something i may have missed? It's a real 
shame that the documentation on this stops around 5 years ago.


IPA devs: is there anything i should be on the lookout for in the dirsrv 
or krb5 logs on the IPA master?  I've disabled the secondary to prevent 
replication from clouding the log events


thanks, everyone

Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575 | www.blue-bolt.com

On 21/12/15 07:57, Nicola Canepa wrote:
Hello, I tried 2 weeks ago from Mavericks (OSX 10.9), but I had the 
opposite problem: kinit works fine, while I'm unable to see users with 
Directory Admin ((it always says it cant' connect, either with or 
without SSL)

I disabled anonymous searches in 389-ds, by the way.

Nicola

Il 21/12/15 07:50, John Obaterspok ha scritto:

Hi Cal,

Does a kinit work from a terminal? Does it work if you use "kinit 
user" or just if you use "kinit user@REALM.suffix"


-- john


2015-12-20 15:09 GMT+01:00 Cal Sawyer >:


Hi, all

I'm attempting to set up LDAP auth (against IPA server 4.10) from
a OSX 10.10.5 (Yosemite) client

Using the excellent instructions at

http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server,
I've populated the specified files, d/l'd the cert, am able to
configure Users and Groups objects/attribs and browse both from
within OSX's Directory Utility. ldapsearch similarly returns the
expected results.

In spite of this, i'm unable to authenticate as any IPA-LDAP user
on this system

dirsrv log on the ipa master shows no apparent errors - remote
auth attempts exit with "RESULT err=0 tag=101 nentries=1
etime=0", but tell the truth, there so much stuff there and being
rather inexperienced with LDAP diags i might easily be missing
something in the details

The linsec.ca  instructions were written in the
10.7-10.8 era so something may have changed since.  Having said
that, we've had no problems authenticating against our existing
OpenLDAP server (which IPA is slated to replace) right up to
10.10.5 with no zero to our Directory Utility setup.

Hoping someone here has some contemporary experience with OSX and
IPA and for whom this issue rings a bell?

many thanks

Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575  |
www.blue-bolt.com 


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






--

Nicola Canepa
Tel: +39-0522-399-3474
canep...@mmfg.it
---
Il contenuto della presente comunicazione è riservato e destinato 
esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona 
diversa dal destinatario sono proibite la diffusione, la distribuzione e la 
copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e 
di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati 
contenuti. La presente comunicazione (comprensiva dei documenti allegati) non 
avrà valore di proposta contrattuale e/o accettazione di proposte provenienti 
dal destinatario, nè rinuncia o riconoscimento di diritti, debiti e/o crediti, 
nè sarà impegnativa, qualora non sia sottoscritto successivo accordo da chi può 
validamente obbligarci. Non deriverà alcuna responsabilità precontrattuale a 
ns. carico, se la presente non sia seguita da contratto sottoscritto dalle 
parti.

The content of the above communication is strictly confidential and reserved 
solely for the referred addressees

[Freeipa-users] NetworkError : invalid continuation byte with utf8 codec

2015-12-21 Thread Gmail
Hi all,

When trying to install on a fresh new Centos 7 I’ve got this error :

2015-12-21T16:04:44Z DEBUG The ipa-server-install command failed, exception: 
NetworkError: cannot connect to 
'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't 
decode byte 0xea in position 13: invalid continuation byte
2015-12-21T16:04:44Z ERROR cannot connect to 
'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't 
decode byte 0xea in position 13: invalid continuation byte

My freeipa-server version is :  4.2.0
I’m running a Centos 3.10.0-327.3.1.el7.x86_64

Any idea of what goes wrong?

-- 
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] RHEL 7.2 update - ns-slapd hanging system

2015-12-21 Thread Andy Thompson
> >>
> >>-Original Message-
> >>From: freeipa-users-boun...@redhat.com  >> users-boun...@redhat.com>  [mailto:freeipa-users-
> >>boun...@redhat.com  ] On
> Behalf Of Petr
> >> Spacek
> >>Sent: Thursday, December 3, 2015 3:04 AM
> >>To: freeipa-users@redhat.com  us...@redhat.com>
> >>Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd
> hanging
> >> system
> >>
> >>On 2.12.2015 22:02, Alexander Bokovoy wrote:
> >>
> >>On Wed, 02 Dec 2015, Andy Thompson wrote:
> >>
> >>Since updating to RHEL 7.2 I've got issues with
> ns-slapd hanging
> >> the
> >>system up after a period of time.  The
> directory becomes
> >> unresponsive
> >>to searches or any connections.  After a
> restart I see
> >>
> >>[02/Dec/2015:15:27:41 -0500] - slapd started.
> >> Listening on All
> >>Interfaces port 389 for LDAP requests
> >>[02/Dec/2015:15:27:41 -0500] - Listening on
> All Interfaces port
> >> 636
> >>for LDAPS requests
> >>[02/Dec/2015:15:27:41 -0500] - Listening on
> >>/var/run/slapd-MHBENP-LIN.socket for
> LDAPI requests
> >>[02/Dec/2015:15:27:44 -0500]
> >> NSMMReplicationPlugin -
> >>agmt="cn=meTomdhixnpipa02.mhbenp.lin"
> >> (mdhixnpipa02:389):
> >>
> >>Replication
> >>
> >>bind with GSSAPI auth resumed
> >>[02/Dec/2015:15:27:47 -0500]
> >> NSMMReplicationPlugin - replication keep
> >>alive entry  >> 4,dc=mhbenp,dc=lin> already exists
> >>
> >>In the logs and occasionally the keepalive
> entry message is seen
> >> a
> >>few times and then eventually the ns-slapd
> taps the system.  100%
> >>util, system load crawls up between 30 and 40
> and eventually I
> >> have
> >>to restart the service to get it to respond
> again.  Memory usage
> >> is
> >>normal, db and entry cache is sufficient..
> >> possibly a little on the
> >>high side but resource is sitting there asking
> to be used :)
> >>
> >>Running 389-ds-base-1.3.4.0-19.el7.x86_64
> after the update
> >> yesterday.
> >>
> >>What additional information can I provide?
> >>
> >>install debuginfo for 389-ds-base and slapi-nis, and
> take a pstack
> >>output for ns-slapd pid.
> >>
> >>
> >>For detailed instructions please see
> >>
> >>http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug
> >> _hangs
> >>
> >>
> >>
> >>Here is the resulting stacktrace during the last hang.
> >>
> >>
> >> The server is idle at this point.  None of the threads are doing any work, 
> >> or
> >> are blocked/deadlocked.  It does not appear hung at all.
> >>
> >> When the server is in the "hung" state again, use ldapsearch (e.g. -s base 
> >> -
> b
> >> "") to "ping" the server to see if it is entirely unresponsive.
> >>
> >>
> >>
> > No ldapsearch does not respond, it just hangs and doesn't ever return.
> 
> Try doing an strace of ldapsearch to see in what system call it is stuck
> in (or you can just do an strace/pstack on the running, hung ldapsearch
> process).
> 


I ended up opening a ticket with Redhat but wanted to pass along that Thierry 
tracked it down to this bug 

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

I bumped up the nsslapd-threadnumber and things have settled down it appears, 
been running since Friday with no issues.

-andy

-- 
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-replica-prepare error: Profile caIPAserviceCert Not Found

2015-12-21 Thread Karl Forner
Hello,

Running:
ipa-replica-prepare ipa-h3s1.example.com --ip-address xx.xx.xx.xx -d -v
fails
with
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA
ipa: DEBUG: request status 200
ipa: DEBUG: request reason_phrase u'OK'
ipa: DEBUG: request headers {'date': 'Mon, 21 Dec 2015 12:50:59 GMT',
'content-length': '148', 'content-type': 'application/xml', 'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: request body '1Profile
caIPAserviceCert Not Found'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute

The context is probably unusual:
I run the command on a replica with CA from a server in freeipa v4.1.4 (in
a adelton/freeipa-server docker)
which is a freeipa v4.2.3  running in
adelton/freeipa-server:lastest-systemd docker

I found this ticket which looks similar:
https://fedorahosted.org/freeipa/ticket/5376

Is there something wrong with my replica knowing that it has been
replicated from a 4.1.4 ?
Is there a work-around ?

Thanks
Karl
-- 
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] OS X Yosemite unable to authenticate

2015-12-21 Thread Ejner Fergo
I've setup some OSX (10.9 + 10.10) machines to authenticate against IPA
(centos 7.x), and like you I've followed the linsec.ca tutorial precisely.
I haven't had problems login in as an IPA user on any system I have setup,
so I'm afraid this reply is pretty useless to you.

Only issue that I had, that the linsec.ca tutorial didn't mention, was
support for nested groups. I managed to figure it out, by adding this Group
object/attribute:

GroupMemberShip / memberUid

Sorry I can't help you, just wanted to let you know it is possible to use.

Best regards,
Ejner Fergo

On Sunday, December 20, 2015, Cal Sawyer  wrote:
> Hi, all
>
> I'm attempting to set up LDAP auth (against IPA server 4.10) from a OSX
10.10.5 (Yosemite) client
>
> Using the excellent instructions at
http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server,
I've populated the specified files, d/l'd the cert, am able to configure
Users and Groups objects/attribs and browse both from within OSX's
Directory Utility.ldapsearch similarly returns the expected results.
>
> In spite of this, i'm unable to authenticate as any IPA-LDAP user on this
system
>
> dirsrv log on the ipa master shows no apparent errors - remote auth
attempts exit with "RESULT err=0 tag=101 nentries=1 etime=0", but tell the
truth, there so much stuff there and being rather inexperienced with LDAP
diags i might easily be missing something in the details
>
> The linsec.ca instructions were written in the 10.7-10.8 era so something
may have changed since.  Having said that, we've had no problems
authenticating against our existing OpenLDAP server (which IPA is slated to
replace) right up to 10.10.5 with no zero to our Directory Utility setup.
>
> Hoping someone here has some contemporary experience with OSX and IPA and
for whom this issue rings a bell?
>
> many thanks
>
> Cal Sawyer | Systems Engineer | BlueBolt Ltd
> 15-16 Margaret Street | London W1W 8RW
> +44 (0)20 7637 5575 | www.blue-bolt.com
>
>
> --
> 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] FreeIPA availability, what to do client side ?

2015-12-21 Thread Petr Spacek
On 21.12.2015 11:36, Alexander Bokovoy wrote:
> On Mon, 21 Dec 2015, bahan w wrote:
>> Hello !
>>
>> I contact you because I have a question relative to high availbility with
>> FreeIPA and replications.
>> In the documentation, we can see information about what to do server side.
>>
>> But I can't find any information about what to do client side.
>>
>> Imagine one of the master server crash, how the client knows where to
>> switch ? What is the configuration to perform to allow this switch.
>>
>> Thank you in advance for these informations !
> Please read archives of this mailing list. There was a thread just a
> week or two ago were this question was answered from multiple angles.

Here is the link:
https://www.redhat.com/archives/freeipa-users/2015-December/msg00184.html

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


Re: [Freeipa-users] FreeIPA availability, what to do client side ?

2015-12-21 Thread Alexander Bokovoy

On Mon, 21 Dec 2015, bahan w wrote:

Hello !

I contact you because I have a question relative to high availbility with
FreeIPA and replications.
In the documentation, we can see information about what to do server side.

But I can't find any information about what to do client side.

Imagine one of the master server crash, how the client knows where to
switch ? What is the configuration to perform to allow this switch.

Thank you in advance for these informations !

Please read archives of this mailing list. There was a thread just a
week or two ago were this question was answered from multiple angles.

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


[Freeipa-users] FreeIPA availability, what to do client side ?

2015-12-21 Thread bahan w
Hello !

I contact you because I have a question relative to high availbility with
FreeIPA and replications.
In the documentation, we can see information about what to do server side.

But I can't find any information about what to do client side.

Imagine one of the master server crash, how the client knows where to
switch ? What is the configuration to perform to allow this switch.

Thank you in advance for these informations !

Best regards.

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

Re: [Freeipa-users] OS X Yosemite unable to authenticate

2015-12-21 Thread Nicola Canepa
Hello, I tried 2 weeks ago from Mavericks (OSX 10.9), but I had the 
opposite problem: kinit works fine, while I'm unable to see users with 
Directory Admin ((it always says it cant' connect, either with or 
without SSL)

I disabled anonymous searches in 389-ds, by the way.

Nicola

Il 21/12/15 07:50, John Obaterspok ha scritto:

Hi Cal,

Does a kinit work from a terminal? Does it work if you use "kinit 
user" or just if you use "kinit user@REALM.suffix"


-- john


2015-12-20 15:09 GMT+01:00 Cal Sawyer >:


Hi, all

I'm attempting to set up LDAP auth (against IPA server 4.10) from
a OSX 10.10.5 (Yosemite) client

Using the excellent instructions at

http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server,
I've populated the specified files, d/l'd the cert, am able to
configure Users and Groups objects/attribs and browse both from
within OSX's Directory Utility.ldapsearch similarly returns
the expected results.

In spite of this, i'm unable to authenticate as any IPA-LDAP user
on this system

dirsrv log on the ipa master shows no apparent errors - remote
auth attempts exit with "RESULT err=0 tag=101 nentries=1 etime=0",
but tell the truth, there so much stuff there and being rather
inexperienced with LDAP diags i might easily be missing something
in the details

The linsec.ca  instructions were written in the
10.7-10.8 era so something may have changed since.  Having said
that, we've had no problems authenticating against our existing
OpenLDAP server (which IPA is slated to replace) right up to
10.10.5 with no zero to our Directory Utility setup.

Hoping someone here has some contemporary experience with OSX and
IPA and for whom this issue rings a bell?

many thanks

Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575  |
www.blue-bolt.com 


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






--

Nicola Canepa
Tel: +39-0522-399-3474
canep...@mmfg.it
---
Il contenuto della presente comunicazione è riservato e destinato 
esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona 
diversa dal destinatario sono proibite la diffusione, la distribuzione e la 
copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e 
di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati 
contenuti. La presente comunicazione (comprensiva dei documenti allegati) non 
avrà valore di proposta contrattuale e/o accettazione di proposte provenienti 
dal destinatario, nè rinuncia o riconoscimento di diritti, debiti e/o crediti, 
nè sarà impegnativa, qualora non sia sottoscritto successivo accordo da chi può 
validamente obbligarci. Non deriverà alcuna responsabilità precontrattuale a 
ns. carico, se la presente non sia seguita da contratto sottoscritto dalle 
parti.

The content of the above communication is strictly confidential and reserved 
solely for the referred addressees. In the event of receipt by persons 
different from the addressee, copying, alteration and distribution are 
forbidden. If received by mistake we ask you to inform us and to destroy and/or 
delete from your computer without using the data herein contained. The present 
message (eventual annexes inclusive) shall not be considered a contractual 
proposal and/or acceptance of offer from the addressee, nor waiver recognizance 
of rights, debts  and/or credits, nor shall it be binding when not executed as 
a subsequent agreement by persons who could lawfully represent us. No 
pre-contractual liability shall apply to us when the present communication is 
not followed by any binding agreement between the parties.

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