Re: [Freeipa-users] ID Views without AD

2016-02-11 Thread Alexander Bokovoy 

On Wed, 10 Feb 2016, Mike Kelly wrote:

On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy 
wrote:


On Wed, 10 Feb 2016, Mike Kelly wrote:

>Is there some extra logging I can turn on to see why this ID View isn't
>being applied like I would expect? Or perhaps some extra bit of
>configuration I missed?
Level 7 or 9 debug logs in SSSD on the client might help.



Thanks.

Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log,
after I ran `sss_cache -E ; id pioto`:

Please provide content of sssd_.log, this is where the actual
work is done when user information is obtained and processed.
sssd_nss.log is merely a requestor.

--
/ 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] BIND apparently not loading ldap.so

2016-02-11 Thread Petr Spacek 
On 10.2.2016 20:05, Chris Lajoie wrote:
> Hi, I am using the bind-dyndb-ldap package (not full FreeIPA) and I am having 
> a problem where it appears that the plugin is not getting loaded by BIND at 
> all. I have nothing in the logs at all from the plugin. No failures of any 
> kind, just regular named startup. I would have expected BIND to provide a log 
> message saying it is loading an external plugin, or at least some kind of 
> initialization message from the plugin itself, but I see neither. What am I 
> doing wrong here?
> 
> This is the relevant portion of my named.conf file:
> 
> logging {
>   channel default_debug {
> file "/var/log/named/named.log" versions 4 size 5m;
> severity info;
> print-time yes;
>   };
> };
> 
> dynamic-db "ldap" {
>   library "ldap.so";
>   arg "uri ldap://ldap.ett.local;;
>   arg "base ou=dns,dc=ett,dc=local";
>   arg "auth_method simple";
>   arg "bind_dn cn=admin,dc=ett,dc=local";
>   arg "password secret";
>   arg "verbose_checks yes";
>   arg "serial_autoincrement yes";
> };

Interesting ...

What version of BIND and bind-dyndb-ldap packages are you using?
$ rpm -q bind bind-dyndb-ldap

I'm not sure how exactly the logging magic in BIND works so I would recommend
you to to run BIND using command:
$ named -g -u named
and check output in the console to see if it contains line like
'bind-dyndb-ldap version 8.0 compiled at 16:09:02 Jan 20 2016, compiler 5.3.1
20151207 (Red Hat 5.3.1-2)'

This message is logged at info level.


If it fails, I would recommend you to double-check that BIND is actually
reading the right configuration file :-) Add line "thismustsurelyfail" to
random places in named.conf and see ;-)

I hope it helps.

-- 
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] PKINIT support in FreeIPA 4.2.0

2016-02-11 Thread Alexander Bokovoy 

On Thu, 11 Feb 2016, Nik Lam wrote:

I've upgraded that package on both the IdM server and the (problem) client.

I haven't looked *really* closely at the logs or the trace output, but it
doesn't look like I'm getting any additional output.

However, on a whim, went to another client. This time I went to check what
version of krb5-pkinit was installed, and discovered it wasn't installed
along with the rest of the ipa-client package dependencies.

I installed the GA version of krb5-pkinit and it all just works!

[testuser@client01-756712 ~]$ kinit -n
[testuser@client01-756712 ~]$
[testuser@client01-756712 ~]$
[testuser@client01-756712 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_84206
Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS

Valid starting   Expires  Service principal
02/10/2016 23:28:46  02/11/2016 23:28:46  krbtgt/example@example.com
[testuser@client01-756712 ~]$
[testuser@client01-756712 ~]$
[testuser@client01-756712 ~]$ kinit -T /tmp/krb5cc_84206 testuser
Enter OTP Token Value:
[testuser@client01-756712 ~]$
[testuser@client01-756712 ~]$
[testuser@client01-756712 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_84206
Default principal: testu...@example.com

Valid starting   Expires  Service principal
02/10/2016 23:29:14  02/11/2016 23:29:07  krbtgt/example@example.com
[testuser@client01-756712 ~]$

So it looks like the absence of the krb5-pkinit package was the reason why
kinit was prompting for the WELLKNOWN/ANONYMOUS password.

To confirm, all that is needed on the client's krb5.conf file is to have
pkinit_anchors pointing to a copy of the belonging to the CA that was used
to create the KDC's cert (which in our case was a self-generated one not
freeIPA/Dogtag's one).

So, I think we've got everything we need to start using it. Thanks again
for your help.

With respect to the future plans - is there anything we need to beware of
in terms of our manual creation of the WELLKNOWN/ANONYMOUS principal via
"kadmin.local -x ipa-setup-override-restrictions"?
Is freeIPA likely to have a fully-integrated anonymous PKINIT solution in
the near future? You people have done such a great job of making the rest
of this stuff easy and well-documented. Hats off to the developers (and Red
Hat for sponsoring the project).

Creating the principal will change, for sure -- we'll most likely add a
generation of it as a special command and will most likely generate it
during the install phase as well. It shouldn't be something that you
need to care about, though, the currently created principal would just
work.

Regarding the rest, we need to discuss with MIT folks some changes to
KDB API to allow KDB drivers to receive client certificates to do actual
PKINIT with certificates which don't have specific extensions. This is
what would be driving the work even though this all might not be needed
for anonymous PKINIT by itself.

--
/ 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] PKINIT support in FreeIPA 4.2.0

2016-02-11 Thread Sumit Bose 
On Thu, Feb 11, 2016 at 11:16:14AM +1100, Nik Lam wrote:
> On Thu, Feb 11, 2016 at 1:42 AM, Sumit Bose  wrote:
> 
> > On Wed, Feb 10, 2016 at 11:07:14PM +1100, Nik Lam wrote:
> > > On Wed, Feb 10, 2016 at 7:43 PM, Sumit Bose  wrote:
> > >
> > > > On Wed, Feb 10, 2016 at 12:07:45PM +1100, Nik Lam wrote:
> > > > > On Wed, Feb 10, 2016 at 3:04 AM, Sumit Bose 
> > wrote:
> > > > >
> > > > > > On Wed, Feb 10, 2016 at 02:08:55AM +1100, Nik Lam wrote:
> > > > > > > On Mon, Feb 8, 2016 at 11:53 PM, Sumit Bose 
> > > > wrote:
> > > > > > >
> > > > > > > > On Thu, Feb 04, 2016 at 07:25:29PM +1100, Nik Lam wrote:
> > > > > > > > > On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose  > >
> > > > wrote:
> > > > > > > > >
> > > > > > > > > > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote:
> > > > > > > > > > > Hello,
> > > > > > > > > > >
> > > > > > > > > > > I installed ipa-server on Centos 7.1 and later did and
> > > > upgrade
> > > > > > of the
> > > > > > > > > > whole
> > > > > > > > > > > system to Centos 7.2.
> > > > > > > > > > >
> > > > > > > > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0
> > > > between
> > > > > > these
> > > > > > > > > > > Centos/RHEL minor releases.
> > > > > > > > > > >
> > > > > > > > > > > We'd now like to try integrating with a 2FA provider via
> > a
> > > > radius
> > > > > > > > proxy
> > > > > > > > > > and
> > > > > > > > > > > want to use anonymous PKINIT to secure the initial
> > > > communications
> > > > > > > > between
> > > > > > > > > > > the client and the KDC.
> > > > > > > > > > >
> > > > > > > > > > > We've tried following the MIT Kerberos PKINIT
> > configuration
> > > > > > > > documentation
> > > > > > > > > > >
> > > > > > > > > > >
> > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html
> > > > > > > > > > >
> > > > > > > > > > > generating our own certs manually with openssl but
> > haven't
> > > > had
> > > > > > any
> > > > > > > > luck.
> > > > > > > > > > > We're seeing this in the kdc log:
> > > > > > > > > > >
> > > > > > > > > > > preauth pkinit failed to initialize: No realms
> > configured
> > > > > > > > correctly
> > > > > > > > > > for
> > > > > > > > > > > pkinit support
> > > > > > > > > >
> > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the
> > IPA
> > > > CA to
> > > > > > > > sign
> > > > > > > > > > the certificate or some other CA?
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I've noticed there are many new pkinit-related options
> > that
> > > > have
> > > > > > been
> > > > > > > > > > added
> > > > > > > > > > > to the ipa-server-install script in 4.2.0, so it looks
> > like
> > > > > > PKINIT is
> > > > > > > > > > > available in this version of FreeIPA. Is that the case?
> > > > > > > > > >
> > > > > > > > > > Which options are you referring to?
> > > > > > > > > >
> > > > > > > > > > bye,
> > > > > > > > > > Sumit
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > And if it is, what is the recommended way to enable it
> > given
> > > > > > that it
> > > > > > > > > > seems
> > > > > > > > > > > to have been disabled in the original install that I
> > did? Or
> > > > > > would it
> > > > > > > > > > just
> > > > > > > > > > > be easier to start from scratch with a 4.2.0
> > > > ipa-server-install?
> > > > > > > > (It's a
> > > > > > > > > > > test instance that doesn't have too much in it - it will
> > > > take a
> > > > > > > > several
> > > > > > > > > > > hours to rebuild from scratch.)
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > >
> > > > > > > > > > > Nik
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > Thanks Sumit.
> > > > > > > > >
> > > > > > > > > It sounds like PKINIT is available but clearly I'm doing it
> > > > wrong.
> > > > > > > > >
> > > > > > > > >  > Which changes did you apply to krb5.conf? Did you use the
> > IPA
> > > > CA
> > > > > > to
> > > > > > > > sign
> > > > > > > > > the certificate or some other CA?
> > > > > > > > >
> > > > > > > > > Actually, I modified the kdc.conf file - placed the kdc.pem,
> > > > > > kdckey.pem
> > > > > > > > and
> > > > > > > > > cacert.pem files in /var/kerberos/krb5kdc/ that I generated
> > via
> > > > > > openssl
> > > > > > > > > commands in the MIT Kerberos documentation. The only change
> > to
> > > > > > kdc.conf
> > > > > > > > > file was to append the location of the kdckey.pem file to
> > > > > > > > pkinit_identity.
> > > > > > > > >
> > > > > > > > >   pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem
> > > > > > > > >   pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem
> > > > > > > > >
> > > > > > > > > became
> > > > > > > > >
> > > > > > > > >   pkinit_identity =
> > > > > > > > >
> > > > FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem
> > > > > > > > >   pkinit_anchors =

Re: [Freeipa-users] BIND apparently not loading ldap.so

2016-02-11 Thread Petr Spacek 
On 11.2.2016 19:32, Chris Lajoie wrote:
> On 02/11/2016 02:46 AM, Petr Spacek wrote:
>> What version of BIND and bind-dyndb-ldap packages are you using? $ rpm 
>> -q bind bind-dyndb-ldap
> bind-9.9.4-29.el7_2.2.x86_64 bind-dyndb-ldap-8.0-1.el7.x86_64
>> 
>> I'm not sure how exactly the logging magic in BIND works so I would 
>> recommend you to to run BIND using command: $ named -g -u named and 
>> check output in the console to see if it contains line like 
>> 'bind-dyndb-ldap version 8.0 compiled at 16:09:02 Jan 20 2016,
>> compiler 5.3.1 20151207 (Red Hat 5.3.1-2)'
> I get nothing like that. Here is the output I get from running named: 
> https://gist.github.com/ctlajoie/0ed4e97e72aec3172a8d

Oh, wait, it seems that you are using views!

Generally we do not test bind-dyndb-ldap with views so there be dragons.

Could you share your named.conf with us?

If you do not want to send it to mailing list feel free to send it to me
privately. My GPG key is attached just for the case you wish to encrypt it.


-- 
Petr^2 Spacek


0x1CB2BB71.asc
Description: application/pgp-keys
-- 
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] CA: Failing to add Centos7 replica to Centos6.7 ipa server

2016-02-11 Thread Quasar 
Thank you!
Dodgig the dogtag guys, then ;-)

Il giorno Gio 11 Feb 2016 13:26 Martin Basti  ha scritto:

>
>
> On 11.02.2016 12:51, Quasar wrote:
>
> Martin,
>
> I've re-tested the replica with a freshly-installed CentOS 7 (1511).
> Installation still fails (damn!) and the log is a bit more verbose. I
> suppose it has something to do with certificate in my master server proably
> due to incremental updates did in the past.
>
> 2016-02-11T11:09:21Z DEBUG Starting external process
> 2016-02-11T11:09:21Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
> '/tmp/tmpRHosRn'
> 2016-02-11T11:10:58Z DEBUG Process finished, return code=1
> 2016-02-11T11:10:58Z DEBUG stdout=Log file:
> /var/log/pki/pki-ca-spawn.20160211120921.log
> Loading deployment configuration from /tmp/tmpRHosRn.
> Installing CA into /var/lib/pki/pki-tomcat.
> Storing deployment configuration into
> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
>
> Installation failed.
>
>
> 2016-02-11T11:10:58Z DEBUG
> stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See:
> https://urllib3.readthedocs.org/en/latest/security.html
>   InsecureRequestWarning)
> pkispawn: WARNING  ... unable to validate security domain
> user/password through REST interface. Interface not available
> pkispawn: ERROR... Exception from Java Configuration Servlet:
> 500 Server Error: Internal Server Error
> pkispawn: ERROR... ParseError: not well-formed (invalid
> token): line 1, column 0:
> {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error
> while updating security domain: java.io.IOException: 2"}
>
> 2016-02-11T11:10:58Z CRITICAL Failed to configure CA instance: Command
> ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpRHosRn'' returned non-zero
> exit status 1
> 2016-02-11T11:10:58Z CRITICAL See the installation logs and the following
> files/directories for more information:
> 2016-02-11T11:10:58Z CRITICAL   /var/log/pki-ca-install.log
> 2016-02-11T11:10:58Z CRITICAL   /var/log/pki/pki-tomcat
> 2016-02-11T11:10:58Z DEBUG Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line 418, in start_creation
> run_step(full_msg, method)
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line 408, in run_step
> method()
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
> line 620, in __spawn_instance
> DogtagInstance.spawn_instance(self, cfg_file)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
> line 201, in spawn_instance
> self.handle_setup_error(e)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
> line 465, in handle_setup_error
> raise RuntimeError("%s configuration failed." % self.subsystem)
> RuntimeError: CA configuration failed.
>
> I'm attaching the 3 log files, as usual:
>
>
>
> On Thu, Feb 11, 2016 at 11:28 AM, Quasar  wrote:
>
>> Hi Martin,
>>
>> first of all thanks for taking some time to read and provide feedback,
>> much appreciated.
>>
>> I firstly tried with CentOS 7.x (build 1511) but got the same errore
>> during CA configuration. Then I supposed I had to upgrade step-by-step,
>> from 3.0 to 3.3 (instead of 3.0 to 4.x) and used Fedora 23, 20, 19 and 18
>> but with no luck.
>> If you need the exact log from CentOS 7.x migration I can provide them to
>> you.
>>
>> About the debug log file, it was attached and these are the final lines
>> containing the error:
>>
>> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: getDomainXML:
>> domainInfo=> standalone="no"?>IPAipaserver.it.fx.lan44344344344380FALSEpki-cadTRUEipaserver-ha.it.fx.lan44344344380443TRUETRUEpki-cad2!
>> t;/Subsyst
>> emCount>0
>> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: Cloning a domain master
>> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase
>> updateDomainXML start hostname=ipaserver.it.fx.lan port=443
>> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateSecurityDomain:
>> failed to update security domain using admin port 443:
>> org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White
>> spaces are required between publicId and systemId.
>> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateSecurityDomain: now
>> trying agent port with client auth
>> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase
>> updateDomainXML start hostname=ipaserver.it.fx.lan port=443
>> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateDomainXML()
>> nickname=subsystemCert cert-pki-ca
>> [09/Feb/2016:15:31:43][http-bio-8443-exec-3]: WizardPanelBase
>> updateDomainXML: status=1
>>
>>
>>
>> --
>> Giuseppe Calignano
>>
>
>
>
> --
> Giuseppe Calignano
>
>
> I'm not sure but it looks like the known bug in dogtag

Re: [Freeipa-users] ID Views without AD

2016-02-11 Thread Jakub Hrozek 
On Thu, Feb 11, 2016 at 10:21:37AM +0200, Alexander Bokovoy wrote:
> On Wed, 10 Feb 2016, Mike Kelly wrote:
> >On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy 
> >wrote:
> >
> >>On Wed, 10 Feb 2016, Mike Kelly wrote:
> >>
> >>>Is there some extra logging I can turn on to see why this ID View isn't
> >>>being applied like I would expect? Or perhaps some extra bit of
> >>>configuration I missed?
> >>Level 7 or 9 debug logs in SSSD on the client might help.
> >>
> >
> >Thanks.
> >
> >Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log,
> >after I ran `sss_cache -E ; id pioto`:
> Please provide content of sssd_.log, this is where the actual
> work is done when user information is obtained and processed.
> sssd_nss.log is merely a requestor.

This wiki page might be helpful:
https://fedorahosted.org/sssd/wiki/Troubleshooting

-- 
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] smart cards caintaining multiple certificates

2016-02-11 Thread Sumit Bose 
On Wed, Feb 10, 2016 at 04:05:20PM -0600, Michael Rainey (Contractor) wrote:
> Greetings,
> 
> I'm curious as to how IPA handles smart cards containing multiple
> certificates.  When I follow the steps listed at
> https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1
> when installing my certificate, I notice the certutil command dumps all
> installed certificates, and dumps the certificates in a different order
> depending on which certificate is selected.  When the server tries to match
> a certificate does it compare all certificates as one long continuous
> string, or does it compare one certificate at a time?  I'm curious if this
> presents a problem for the end-user or has this problem been addressed?

SSSD looks for valid certificates which have client authentication set
in the extended key usage. If multiple certificate are found currently
just the "first" one is used. More option to configure the certificate
selection are planned for the next release.

If you have a specific selection of certificates on the Smartcards you
use which currently do not work as expected with SSSD feel free to send
me a dump of the certificates on the card or a description so that I can
see what kind of configuration options might be needed to select the
right one. If you  prefer you can send this data to me directly.

HTH

bye,
Sumit

> -- 
> *Michael Rainey*

> -- 
> 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] Failing to add Fedora 20 replica to Centos6.7 ipa server

2016-02-11 Thread Martin Basti 

Hello,
comments inline.

On 11.02.2016 10:46, Quasar wrote:

Hi, I desperately need your help/advice with our ipa update process.
Briefly, we'd like to update our IPA 3.0 installation based on CentOS 
6.7 to a newer version, and I read that the way of doing it is to 
create a new replica with a newer version of IPA server.
Before writing this post, I browsed for similar issues (there are many 
of them with similar outcome) and tried to apply the suggested 
solutions but no luck. I also tried previous versions of Fedora (18 
and 19) but again no luck.

It seems I'm stuck and I don't know how to proceed :(

Thank you in advance to anyhow who will take the time to read my 
message :) Let's start!


Right now we have a single running on Centos 6.7, and we are planning 
to create a replica with Fedora 20 which has IPA 3.3


Fedora 20 is end of life, why you use that old fedora?
Why not Centos7 or F23 ?

Upgrade path from CentOS to Fedora is supported or tested, there might 
be issues because versions of FreeIPA are different due backporting 
patches to CentOS


I suggest to use new FreeIPA 4.2 on centos 7.


Here are the details of the master (CentOS 6.7, hostname ipaserver)
[root@ipaserver ~]# uname -a
Linux ipaserver.it.fx.lan 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 
12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux


[root@ipaserver ~]# rpm -qa|grep -E 'freeipa-server|pki-ca'
ipa-pki-ca-theme-9.0.3-7.el6.noarch
pki-ca-9.0.3-43.el6.noarch

And here are the details of the replica (Fedoraa 20, hostname 
ipaserver-ha2)

[root@ipaserver-ha2 ~]# uname -a
Linux ipaserver-ha2.it.fx.lan 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 
17:08:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux


[root@ipaserver-ha2 ~]# rpm -qa|grep -E 'freeipa-server|pki-ca'
pki-ca-10.1.2-7.fc20.noarch
freeipa-server-3.3.5-1.fc20.x86_64

Here are the steps I made:
Before starting the replica I updated the schema of the master with 
the copy-schema-to-ca.py script
I prepared the replica certificates on the server 
("ipa-replica-prepare ipaserver-ha2.it.fx.lan --ip-address 10.0.0.10") 
and transferred to the replica server on the same folder

The I ran the replica install and here's the output:
[root@ipaserver-ha2 ~]# ipa-replica-install --setup-ca --setup-dns 
--no-forwarders --no-ntp 
/var/lib/ipa/replica-info-ipaserver-ha2.it.fx.lan.gpg

Directory Manager (existing master) password:

Run connection check to master
Check connection from replica to remote master 'ipaserver.it.fx.lan':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK
   PKI-CA: Directory Service port (7389): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
ad...@it.fx.lan password:

Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'ipaserver-ha2.it.fx.lan':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

Connection from master to replica is OK.

Connection check OK
Configuring directory server (dirsrv): Estimated time 1 minute
  [1/34]: creating directory server user
  [2/34]: creating directory server instance
  [3/34]: adding default schema
  [4/34]: enabling memberof plugin
  [5/34]: enabling winsync plugin
  [6/34]: configuring replication version plugin
  [7/34]: enabling IPA enrollment plugin
  [8/34]: enabling ldapi
  [9/34]: configuring uniqueness plugin
  [10/34]: configuring uuid plugin
  [11/34]: configuring modrdn plugin
  [12/34]: configuring DNS plugin
  [13/34]: enabling entryUSN plugin
  [14/34]: configuring lockout plugin
  [15/34]: creating indices
  [16/34]: enabling referential integrity plugin
  [17/34]: configuring ssl for ds instance
  [18/34]: configuring certmap.conf
  [19/34]: configure autobind for root
  [20/34]: configure new location for managed entries
  [21/34]: configure dirsrv ccache
  [22/34]: enable SASL mapping fallback
  [23/34]: restarting directory server
  [24/34]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 3 seconds elapsed
Update succeeded

  [25/34]: updating schema
  [26/34]: setting Auto Member configuration
  [27/34]: enabling S4U2Proxy delegation
  [28/34]: initializing group membership
  [29/34]: adding master entry
  [30/34]: configuring Posix uid/gid generation
  [31/34]: adding replication acis
  [32/34]: enabling

Re: [Freeipa-users] CA: Failing to add Centos7 replica to Centos6.7 ipa server

2016-02-11 Thread Martin Basti 



On 11.02.2016 12:51, Quasar wrote:

Martin,

I've re-tested the replica with a freshly-installed CentOS 7 (1511).
Installation still fails (damn!) and the log is a bit more verbose. I 
suppose it has something to do with certificate in my master server 
proably due to incremental updates did in the past.


2016-02-11T11:09:21Z DEBUG Starting external process
2016-02-11T11:09:21Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f' 
'/tmp/tmpRHosRn'

2016-02-11T11:10:58Z DEBUG Process finished, return code=1
2016-02-11T11:10:58Z DEBUG stdout=Log file: 
/var/log/pki/pki-ca-spawn.20160211120921.log

Loading deployment configuration from /tmp/tmpRHosRn.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into 
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.


Installation failed.


2016-02-11T11:10:58Z DEBUG 
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: 
InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
certificate verification is strongly advised. See: 
https://urllib3.readthedocs.org/en/latest/security.html

  InsecureRequestWarning)
pkispawn: WARNING  ... unable to validate security domain 
user/password through REST interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration 
Servlet: 500 Server Error: Internal Server Error
pkispawn: ERROR... ParseError: not well-formed (invalid 
token): line 1, column 0: 
{"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error 
while updating security domain: java.io.IOException: 2"}


2016-02-11T11:10:58Z CRITICAL Failed to configure CA instance: Command 
''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpRHosRn'' returned 
non-zero exit status 1
2016-02-11T11:10:58Z CRITICAL See the installation logs and the 
following files/directories for more information:

2016-02-11T11:10:58Z CRITICAL   /var/log/pki-ca-install.log
2016-02-11T11:10:58Z CRITICAL   /var/log/pki/pki-tomcat
2016-02-11T11:10:58Z DEBUG Traceback (most recent call last):
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
418, in start_creation

run_step(full_msg, method)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
408, in run_step

method()
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", 
line 620, in __spawn_instance

DogtagInstance.spawn_instance(self, cfg_file)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 
201, in spawn_instance

self.handle_setup_error(e)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 
465, in handle_setup_error

raise RuntimeError("%s configuration failed." % self.subsystem)
RuntimeError: CA configuration failed.

I'm attaching the 3 log files, as usual:



On Thu, Feb 11, 2016 at 11:28 AM, Quasar > wrote:


Hi Martin,

first of all thanks for taking some time to read and provide
feedback, much appreciated.

I firstly tried with CentOS 7.x (build 1511) but got the same
errore during CA configuration. Then I supposed I had to upgrade
step-by-step, from 3.0 to 3.3 (instead of 3.0 to 4.x) and used
Fedora 23, 20, 19 and 18 but with no luck.
If you need the exact log from CentOS 7.x migration I can provide
them to you.

About the debug log file, it was attached and these are the final
lines containing the error:

[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: getDomainXML:
domainInfo=IPAipaserver.it.fx.lan44344344344380FALSEpki-cadTRUEipaserver-ha.it.fx.lan44344344380443TRUETRUEpki-cad20
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: Cloning a domain master
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase
updateDomainXML start hostname=ipaserver.it.fx.lan port=443
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]:
updateSecurityDomain: failed to update security domain using admin
port 443: org.xml.sax.SAXParseException; lineNumber: 1;
columnNumber: 50; White spaces are required between publicId and
systemId.
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]:
updateSecurityDomain: now trying agent port with client auth
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase
updateDomainXML start hostname=ipaserver.it.fx.lan port=443
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateDomainXML()
nickname=subsystemCert cert-pki-ca
[09/Feb/2016:15:31:43][http-bio-8443-exec-3]: WizardPanelBase
updateDomainXML: status=1



-- 
Giuseppe Calignano





--
Giuseppe Calignano


I'm not sure but it looks like the known bug in dogtag 9 and 10 
compatibility (I will try to find related bugzillas).
This should be already fixed in RHEL, so I do not know when it will hit 
CentOS or if it is already there.


pkispawn: WARNING ... unable to validate

Re: [Freeipa-users] Failing to add Fedora 20 replica to Centos6.7 ipa server

2016-02-11 Thread Martin Basti 



On 11.02.2016 11:05, Martin Basti wrote:

Hello,
comments inline.

On 11.02.2016 10:46, Quasar wrote:

Hi, I desperately need your help/advice with our ipa update process.
Briefly, we'd like to update our IPA 3.0 installation based on CentOS 
6.7 to a newer version, and I read that the way of doing it is to 
create a new replica with a newer version of IPA server.
Before writing this post, I browsed for similar issues (there are 
many of them with similar outcome) and tried to apply the suggested 
solutions but no luck. I also tried previous versions of Fedora (18 
and 19) but again no luck.

It seems I'm stuck and I don't know how to proceed :(

Thank you in advance to anyhow who will take the time to read my 
message :) Let's start!


Right now we have a single running on Centos 6.7, and we are planning 
to create a replica with Fedora 20 which has IPA 3.3


Fedora 20 is end of life, why you use that old fedora?
Why not Centos7 or F23 ?

Upgrade path from CentOS to Fedora is supported or tested, there might 
be issues because versions of FreeIPA are different due backporting 
patches to CentOS

* is NOT supported

sorry


I suggest to use new FreeIPA 4.2 on centos 7.


Here are the details of the master (CentOS 6.7, hostname ipaserver)
[root@ipaserver ~]# uname -a
Linux ipaserver.it.fx.lan 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 
12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux


[root@ipaserver ~]# rpm -qa|grep -E 'freeipa-server|pki-ca'
ipa-pki-ca-theme-9.0.3-7.el6.noarch
pki-ca-9.0.3-43.el6.noarch

And here are the details of the replica (Fedoraa 20, hostname 
ipaserver-ha2)

[root@ipaserver-ha2 ~]# uname -a
Linux ipaserver-ha2.it.fx.lan 3.19.8-100.fc20.x86_64 #1 SMP Tue May 
12 17:08:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux


[root@ipaserver-ha2 ~]# rpm -qa|grep -E 'freeipa-server|pki-ca'
pki-ca-10.1.2-7.fc20.noarch
freeipa-server-3.3.5-1.fc20.x86_64

Here are the steps I made:
Before starting the replica I updated the schema of the master with 
the copy-schema-to-ca.py script
I prepared the replica certificates on the server 
("ipa-replica-prepare ipaserver-ha2.it.fx.lan --ip-address 
10.0.0.10") and transferred to the replica server on the same folder

The I ran the replica install and here's the output:
[root@ipaserver-ha2 ~]# ipa-replica-install --setup-ca --setup-dns 
--no-forwarders --no-ntp 
/var/lib/ipa/replica-info-ipaserver-ha2.it.fx.lan.gpg

Directory Manager (existing master) password:

Run connection check to master
Check connection from replica to remote master 'ipaserver.it.fx.lan':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK
   PKI-CA: Directory Service port (7389): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
ad...@it.fx.lan password:

Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'ipaserver-ha2.it.fx.lan':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

Connection from master to replica is OK.

Connection check OK
Configuring directory server (dirsrv): Estimated time 1 minute
  [1/34]: creating directory server user
  [2/34]: creating directory server instance
  [3/34]: adding default schema
  [4/34]: enabling memberof plugin
  [5/34]: enabling winsync plugin
  [6/34]: configuring replication version plugin
  [7/34]: enabling IPA enrollment plugin
  [8/34]: enabling ldapi
  [9/34]: configuring uniqueness plugin
  [10/34]: configuring uuid plugin
  [11/34]: configuring modrdn plugin
  [12/34]: configuring DNS plugin
  [13/34]: enabling entryUSN plugin
  [14/34]: configuring lockout plugin
  [15/34]: creating indices
  [16/34]: enabling referential integrity plugin
  [17/34]: configuring ssl for ds instance
  [18/34]: configuring certmap.conf
  [19/34]: configure autobind for root
  [20/34]: configure new location for managed entries
  [21/34]: configure dirsrv ccache
  [22/34]: enable SASL mapping fallback
  [23/34]: restarting directory server
  [24/34]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 3 seconds elapsed
Update succeeded

  [25/34]: updating schema
  [26/34]: setting Auto Member configuration
  [27/34]: enabling S4U2Proxy delegation
  [28/34]: initializing group membership
  [29/34]: adding master entry
  [30/34]: configuring Posix uid/gid

Re: [Freeipa-users] ID Views without AD

2016-02-11 Thread Mike Kelly 
On Thu, Feb 11, 2016 at 3:21 AM Alexander Bokovoy 
wrote:

> On Wed, 10 Feb 2016, Mike Kelly wrote:
> >On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy 
> >wrote:
> >
> >> On Wed, 10 Feb 2016, Mike Kelly wrote:
> >>
> >> >Is there some extra logging I can turn on to see why this ID View isn't
> >> >being applied like I would expect? Or perhaps some extra bit of
> >> >configuration I missed?
> >> Level 7 or 9 debug logs in SSSD on the client might help.
> >>
> >
> >Thanks.
> >
> >Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log,
> >after I ran `sss_cache -E ; id pioto`:
> Please provide content of sssd_.log, this is where the actual
> work is done when user information is obtained and processed.
> sssd_nss.log is merely a requestor.
>

 Thanks. Here's what is hopefully the relevant lines:


(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]]
[sdap_search_user_next_base] (0x0400): Searching for users with base
[cn=accounts,dc=home,dc=pioto,dc=org]
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(uid=pioto)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0
][cn=accounts,dc=home,dc=pioto,dc=org].
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_parse_entry]
(0x1000): OriginalDN:
[uid=pioto,cn=users,cn=accounts,dc=home,dc=pioto,dc=org].
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]]
[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no
errmsg set
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]]
[sdap_search_user_process] (0x0400): Search for users, returned 1 results.
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user]
(0x0400): Save user
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]]
[sdap_attrs_get_sid_str] (0x1000): No [objectSIDString] attribute.
[0][Success]
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]]
[sdap_get_primary_name] (0x0400): Processing object pioto
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user]
(0x0400): Processing user pioto
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]]
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)]
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user]
(0x0400): Adding original memberOf attributes to [pioto].
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user]
(0x0400): Adding user principal [pi...@home.pioto.org] to attributes of
[pioto].
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user]
(0x0400): Storing info for user pioto
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [acctinfo_callback]
(0x0100): Request processed. Returned 0,0,Success (Success)

-- so, looks like i don't see any evidence of an id view being searched for
or applied?

(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [be_get_account_info]
(0x0200): Got request for [0x1002][1][idnumber=140341]
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]]
[sdap_get_groups_next_base] (0x0400): Searching for groups with base
[cn=accounts,dc=home,dc=pioto,dc=org]
(Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(gidNumber=140341)(|(objectClass=ipaUserGroup)(objectClass=posixGroup
))(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=accounts,dc=home,dc=pioto,dc=org].

-- and here, looks like nss is requesting the details from my FreeIPA
default GID...

The only log entries I see in /var/log/sssd/sssd_.log that are
related to views seem to be from when I last restarted sssd:

(Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_get_options]
(0x0400): Option ipa_views_search_base has no value
(Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [ipa_get_id_options]
(0x0100): Option ipa_views_search_base set to
cn=views,cn=accounts,dc=home,dc=pioto,dc=org
(Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]]
[common_parse_search_base] (0x0100): Search base added:
[IPA_VIEWS][cn=views,cn=accounts,dc=home,dc=pioto,dc=org][SUBTREE][]
(Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [sdap_get_map]
(0x0400): Option ipa_view_class has value nsContainer
(Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [sdap_get_map]
(0x0400): Option ipa_view_name has value cn
(Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [sssm_ipa_id_init]
(0x0020): Cannot find view name in the cache. Will do online lookup later.
(Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_copy_options_ex]
(0x0400): Option ipa_views_search_base has value
cn=views,cn=accounts,dc=home,dc=pioto,dc=org
(Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_copy_options_ex]
(0x0400): Option ipa_views_search_base has value
cn=views,cn=accounts,dc=home,dc=pioto,dc=org



When I search LDAP under that search base, I get 3 DNs I'd expect to see:

dn: cn=views,cn=accounts,dc=home,dc=pioto,dc=org

Re: [Freeipa-users] ID Views without AD

2016-02-11 Thread Mike Kelly 
On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy 
wrote:

> On Wed, 10 Feb 2016, Mike Kelly wrote:
>
> >Is there some extra logging I can turn on to see why this ID View isn't
> >being applied like I would expect? Or perhaps some extra bit of
> >configuration I missed?
> Level 7 or 9 debug logs in SSSD on the client might help.
>

Thanks.

Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log,
after I ran `sss_cache -E ; id pioto`:

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running
command [17] with input [pioto].

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name 'pioto' matched without domain, user is pioto

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
Requesting info for [pioto] from []

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
Requesting info for [pi...@home.pioto.org]

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a
LOCAL view, continuing with provided values.

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x7f9b482220e0:1:pi...@home.pioto.org]

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [home.pioto.org][4097][1][name=pioto]

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x7f9b482220e0:1:pi...@home.pioto.org]

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got
reply from Data Provider - DP error code: 0 errno: 0 error message: Success
(Success)

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
Requesting info for [pi...@home.pioto.org]

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0400):
Returning info for user [pi...@home.pioto.org]

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x7f9b482220e0:1:pi...@home.pioto.org]

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getbyid] (0x0400): Running
command [34] with id [140341].

(Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getgrgid_search] (0x0100):
Requesting info for [1403400...@home.pioto.org]



So, if I'm reading that right, it looks like we first query the server to
find the user with name 'pioto', and then get back a response containing my
IPA-assigned UID, and do a further lookup on that... it mentions "Not a
LOCAL view, ...", but I'm not sure that's related?
So, I wonder if there's some bit of client-side configuration that I'm
missing? But, the bit that I see in /var/log/sssd/sssd_home.pioto.org.log
seems to match up with what I can see in LDAP:

(Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_copy_options_ex]
(0x0400): Option ipa_views_search_base has value
cn=views,cn=accounts,dc=home,dc=pioto,dc=org



>I'm running a pair of CentOS 7 boxes, one acting as the FreeIPA server, and
> >the other is the "legacy" box I want to shim FreeIPA into...
> ID Views are only applied on machines where you have SSSD that supports
> them, just to make sure.
>

Thanks. Both server and client are running:

$ sssd --version
1.13.0

-- 

Mike Kelly
-- 
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] CA: Failing to add Centos7 replica to Centos6.7 ipa server

2016-02-11 Thread Martin Basti 



On 11.02.2016 13:33, Quasar wrote:


Thank you!
Dodgig the dogtag guys, then ;-)


Do you have CA configured as external CA?

It could be:
https://bugzilla.redhat.com/show_bug.cgi?id=1291747

I don't think that it is already in CentOS



Il giorno Gio 11 Feb 2016 13:26 Martin Basti > ha scritto:




On 11.02.2016 12:51, Quasar wrote:

Martin,

I've re-tested the replica with a freshly-installed CentOS 7 (1511).
Installation still fails (damn!) and the log is a bit more
verbose. I suppose it has something to do with certificate in my
master server proably due to incremental updates did in the past.

2016-02-11T11:09:21Z DEBUG Starting external process
2016-02-11T11:09:21Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA'
'-f' '/tmp/tmpRHosRn'
2016-02-11T11:10:58Z DEBUG Process finished, return code=1
2016-02-11T11:10:58Z DEBUG stdout=Log file:
/var/log/pki/pki-ca-spawn.20160211120921.log
Loading deployment configuration from /tmp/tmpRHosRn.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.

Installation failed.


2016-02-11T11:10:58Z DEBUG
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769:
InsecureRequestWarning: Unverified HTTPS request is being made.
Adding certificate verification is strongly advised. See:
https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
pkispawn: WARNING  ... unable to validate security domain
user/password through REST interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration
Servlet: 500 Server Error: Internal Server Error
pkispawn: ERROR... ParseError: not well-formed
(invalid token): line 1, column 0:

{"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error
while updating security domain: java.io.IOException: 2"}

2016-02-11T11:10:58Z CRITICAL Failed to configure CA instance:
Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpRHosRn''
returned non-zero exit status 1
2016-02-11T11:10:58Z CRITICAL See the installation logs and the
following files/directories for more information:
2016-02-11T11:10:58Z CRITICAL /var/log/pki-ca-install.log
2016-02-11T11:10:58Z CRITICAL /var/log/pki/pki-tomcat
2016-02-11T11:10:58Z DEBUG Traceback (most recent call last):
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 418, in start_creation
run_step(full_msg, method)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 408, in run_step
method()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 620, in __spawn_instance
DogtagInstance.spawn_instance(self, cfg_file)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
line 201, in spawn_instance
self.handle_setup_error(e)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
line 465, in handle_setup_error
raise RuntimeError("%s configuration failed." % self.subsystem)
RuntimeError: CA configuration failed.

I'm attaching the 3 log files, as usual:



On Thu, Feb 11, 2016 at 11:28 AM, Quasar > wrote:

Hi Martin,

first of all thanks for taking some time to read and provide
feedback, much appreciated.

I firstly tried with CentOS 7.x (build 1511) but got the same
errore during CA configuration. Then I supposed I had to
upgrade step-by-step, from 3.0 to 3.3 (instead of 3.0 to 4.x)
and used Fedora 23, 20, 19 and 18 but with no luck.
If you need the exact log from CentOS 7.x migration I can
provide them to you.

About the debug log file, it was attached and these are the
final lines containing the error:

[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: getDomainXML:
domainInfo=IPAipaserver.it.fx.lan44344344344380FALSEpki-cadTRUEipaserver-ha.it.fx.lan44344344380443TRUETRUEpki-cad2!
t;/Subsyst

emCount>0
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: Cloning a
domain master
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase
updateDomainXML start hostname=ipaserver.it.fx.lan port=443
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]:
updateSecurityDomain: failed to update security domain using
admin port 443: org.xml.sax.SAXParseException; lineNumber: 1;
columnNumber: 50; White spaces are required between publicId
and systemId.
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]:
updateSecurityDomain: now trying agent

Re: [Freeipa-users] CA: Failing to add Centos7 replica to Centos6.7 ipa server

2016-02-11 Thread Quasar 
​
Excellent news Martin! After checking the bug you shared with me, I tried
to check if pki-core-9.0.3-45.el6_7 was released for CentOS 6.7 and I was
quite lucky this time!
After a "yum update" I retried the teplica and this time everything went
smoothly!

Thanks a lot for your help and time!

Cheers!



On Thu, Feb 11, 2016 at 2:04 PM, Martin Basti  wrote:

>
>
> On 11.02.2016 13:33, Quasar wrote:
>
> Thank you!
> Dodgig the dogtag guys, then ;-)
>
> Do you have CA configured as external CA?
>
> It could be:
> https://bugzilla.redhat.com/show_bug.cgi?id=1291747
>
> I don't think that it is already in CentOS
>
>


-- 
Giuseppe Calignano
-- 
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] Failing to add Fedora 20 replica to Centos6.7 ipa server

2016-02-11 Thread Quasar 
Please disregard this email, as it was duplicated.

Sorry for the incovenience

On Tue, Feb 9, 2016 at 4:26 PM,  wrote:

> Hi, I desperately need your help/advice with our ipa update process.
> Briefly, we'd like to update our IPA 3.0 installation based on CentOS 6.7
> to a newer version, and I read that the way of doing it is to create a new
> replica with a newer version of IPA server.
> Before writing this post, I browsed for similar issues (there are many of
> them with similar outcome) and tried to apply the suggested solutions but
> no luck. I also tried previous versions of Fedora (18 and 19) but again no
> luck.
> It seems I'm stuck and I don't know how to proceed :(
>
> Thank you in advance to anyhow who will take the time to read my message
> :) Let's start!
>
> Right now we have a single running on Centos 6.7, and we are planning to
> create a replica with Fedora 20 which has IPA 3.3
>
> Here are the details of the master (ipaserver)
> [root@ipaserver ~]# uname -a
> Linux ipaserver.it.fx.lan 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21
> UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> [root@ipaserver ~]# rpm -qa|grep -E 'freeipa-server|pki-ca'
> ipa-pki-ca-theme-9.0.3-7.el6.noarch
> pki-ca-9.0.3-43.el6.noarch
>
> And here are the details of the replica (ipaserver-ha2
> Replica server on Fedora 20:
> [root@ipaserver-ha2 ~]# uname -a
> Linux ipaserver-ha2.it.fx.lan 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12
> 17:08:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> [root@ipaserver-ha2 ~]# rpm -qa|grep -E 'freeipa-server|pki-ca'
> pki-ca-10.1.2-7.fc20.noarch
> freeipa-server-3.3.5-1.fc20.x86_64
>
> Here are the steps I made:
>
>- Before starting the replica I updated the schema of the master with
>the copy-schema-to-ca.py script
>- I prepared the replica certificates on the server
>("ipa-replica-prepare ipaserver-ha2.it.fx.lan --ip-address 10.0.0.10") and
>transferred to the replica server on the same folder
>- The I ran the replica install and here's the output:
>
> [root@ipaserver-ha2 ~]# ipa-replica-install --setup-ca --setup-dns
> --no-forwarders --no-ntp
> /var/lib/ipa/replica-info-ipaserver-ha2.it.fx.lan.gpg
> Directory Manager (existing master) password:
>
> Run connection check to master
> Check connection from replica to remote master 'ipaserver.it.fx.lan':
>Directory Service: Unsecure port (389): OK
>Directory Service: Secure port (636): OK
>Kerberos KDC: TCP (88): OK
>Kerberos Kpasswd: TCP (464): OK
>HTTP Server: Unsecure port (80): OK
>HTTP Server: Secure port (443): OK
>PKI-CA: Directory Service port (7389): OK
>
> The following list of ports use UDP protocol and would need to be
> checked manually:
>Kerberos KDC: UDP (88): SKIPPED
>Kerberos Kpasswd: UDP (464): SKIPPED
>
> Connection from replica to master is OK.
> Start listening on required ports for remote master check
> Get credentials to log in to remote master
> ad...@it.fx.lan password:
>
> Check SSH connection to remote master
> Execute check on remote master
> Check connection from master to remote replica 'ipaserver-ha2.it.fx.lan':
>Directory Service: Unsecure port (389): OK
>Directory Service: Secure port (636): OK
>Kerberos KDC: TCP (88): OK
>Kerberos KDC: UDP (88): OK
>Kerberos Kpasswd: TCP (464): OK
>Kerberos Kpasswd: UDP (464): OK
>HTTP Server: Unsecure port (80): OK
>HTTP Server: Secure port (443): OK
>
> Connection from master to replica is OK.
>
> Connection check OK
> Configuring directory server (dirsrv): Estimated time 1 minute
>   [1/34]: creating directory server user
>   [2/34]: creating directory server instance
>   [3/34]: adding default schema
>   [4/34]: enabling memberof plugin
>   [5/34]: enabling winsync plugin
>   [6/34]: configuring replication version plugin
>   [7/34]: enabling IPA enrollment plugin
>   [8/34]: enabling ldapi
>   [9/34]: configuring uniqueness plugin
>   [10/34]: configuring uuid plugin
>   [11/34]: configuring modrdn plugin
>   [12/34]: configuring DNS plugin
>   [13/34]: enabling entryUSN plugin
>   [14/34]: configuring lockout plugin
>   [15/34]: creating indices
>   [16/34]: enabling referential integrity plugin
>   [17/34]: configuring ssl for ds instance
>   [18/34]: configuring certmap.conf
>   [19/34]: configure autobind for root
>   [20/34]: configure new location for managed entries
>   [21/34]: configure dirsrv ccache
>   [22/34]: enable SASL mapping fallback
>   [23/34]: restarting directory server
>   [24/34]: setting up initial replication
> Starting replication, please wait until this has completed.
> Update in progress, 3 seconds elapsed
> Update succeeded
>
>   [25/34]: updating schema
>   [26/34]: setting Auto Member configuration
>   [27/34]: enabling S4U2Proxy delegation
>   [28/34]: initializing group membership
>   [29/34]: adding master entry
>   [30/34]: configuring Posix uid/gid generation
>   [31/34]: adding replication acis
>   [32/34]:

Re: [Freeipa-users] CA: Failing to add Centos7 replica to Centos6.7 ipa server [solved]

2016-02-11 Thread Martin Basti 



On 11.02.2016 14:49, Quasar wrote:

​
Excellent news Martin! After checking the bug you shared with me, I 
tried to check if pki-core-9.0.3-45.el6_7 was released for CentOS 6.7 
and I was quite lucky this time!
After a "yum update" I retried the teplica and this time everything 
went smoothly!


Thanks a lot for your help and time!

Cheers!


You are welcome

Just note:
If you plan to retire old server, do not forget to set new IPA CA server 
as CRL master and renewal master

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




On Thu, Feb 11, 2016 at 2:04 PM, Martin Basti > wrote:




On 11.02.2016 13:33, Quasar wrote:


Thank you!
Dodgig the dogtag guys, then ;-)


Do you have CA configured as external CA?

It could be:
https://bugzilla.redhat.com/show_bug.cgi?id=1291747

I don't think that it is already in CentOS




--
Giuseppe Calignano


-- 
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] Failing to add Fedora 20 replica to Centos6.7 ipa server

2016-02-11 Thread Quasar 
Hi Martin,

first of all thanks for taking some time to read and provide feedback, much
appreciated.

I firstly tried with CentOS 7.x (build 1511) but got the same errore during
CA configuration. Then I supposed I had to upgrade step-by-step, from 3.0
to 3.3 (instead of 3.0 to 4.x) and used Fedora 23, 20, 19 and 18 but with
no luck.
If you need the exact log from CentOS 7.x migration I can provide them to
you.

About the debug log file, it was attached and these are the final lines
containing the error:

[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: getDomainXML:
domainInfo=IPAipaserver.it.fx.lan44344344344380FALSEpki-cadTRUEipaserver-ha.it.fx.lan44344344380443TRUETRUEpki-cad20
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: Cloning a domain master
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase
updateDomainXML start hostname=ipaserver.it.fx.lan port=443
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateSecurityDomain: failed
to update security domain using admin port 443:
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White
spaces are required between publicId and systemId.
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateSecurityDomain: now
trying agent port with client auth
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase
updateDomainXML start hostname=ipaserver.it.fx.lan port=443
[09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateDomainXML()
nickname=subsystemCert cert-pki-ca
[09/Feb/2016:15:31:43][http-bio-8443-exec-3]: WizardPanelBase
updateDomainXML: status=1



-- 
Giuseppe Calignano
-- 
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] BIND apparently not loading ldap.so

2016-02-11 Thread Chris Lajoie 

On 02/11/2016 02:46 AM, Petr Spacek wrote:

What version of BIND and bind-dyndb-ldap packages are you using?
$ rpm -q bind bind-dyndb-ldap

bind-9.9.4-29.el7_2.2.x86_64
bind-dyndb-ldap-8.0-1.el7.x86_64


I'm not sure how exactly the logging magic in BIND works so I would recommend
you to to run BIND using command:
$ named -g -u named
and check output in the console to see if it contains line like
'bind-dyndb-ldap version 8.0 compiled at 16:09:02 Jan 20 2016, compiler 5.3.1
20151207 (Red Hat 5.3.1-2)'

I get nothing like that. Here is the output I get from running named:
https://gist.github.com/ctlajoie/0ed4e97e72aec3172a8d



This message is logged at info level.


If it fails, I would recommend you to double-check that BIND is actually
reading the right configuration file :-) Add line "thismustsurelyfail" to
random places in named.conf and see ;-)
I had previously been thinking along the same lines and I tried this (I 
actually just removed the semicolon from the end of the dynamic-db 
block). As expected, named fails to start with a configuration error. I 
tried it again just now to confirm.. same result.



Thank you Petr, I appreciate you taking the time to help.

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