[Freeipa-users] FreeIPA upgrade from ipa-server-4.2.0-15.0.1.el7.centos.18 to ipa-server-4.2.0-15.0.1.el7.centos.19 (went sideways)

2016-09-22 Thread Devin Acosta 
Tonight,

I noticed there was like 30 packages to be applied on my IPA server. I did
the normal 'yum update' process and it completed. I then rebooted the box
for the new kernel to take affect and then that is when IPA stopped working
completely.

When I try to start the dirsrv@RSINC-LOCAL.service, it throws up with:

[23/Sep/2016:05:19:38 +] - SSL alert: Configured NSS Ciphers
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert:
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_256_GCM_SHA384:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA:
enabled
[23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled
[23/Sep/2016:05:19:38 +] SSL Initialization - Configured SSL version
range: min: TLS1.0, max: TLS1.2
[23/Sep/2016:05:19:38 +] - Shutting down due to possible conflicts with
other slapd processes

*I am not sure what to do about the error "Shutting down due to possible
conflicts with other slapd processes"??*
The dirserv won't start, and therefore IPA won't start either. Is there
some way to do some cleanup or to have it repair the issue?

Any help is greatly appreciated!!!

Devin.
-- 
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] Fwd: Re: Increase ListenBacklog for httpd

2016-09-22 Thread Robbie Harwood 
Rakesh Rajasekharan  writes:

> Thanks Robbie for the inputs.. the load should not have been high as I
> have around 4000 clients with 160 users which should be manageable
>
> However, I saw a lot of clock skew too great errors in my
> krb5kdc.log...  however I haven't been able to verify if those were
> genuine...
>
> Can too many clock skew errors take down the kerberos service..

Too much load of any kind will take down the service, but clock skew
problems shouldn't be particularly resource intensive.  Depending on
your client behavior, they may cause retries, which will mean about
twice as much traffic as normal, if memory serves.

You'll want to fix the clock skew problem regardless.


signature.asc
Description: PGP signature
-- 
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] Problem with a filer and FreeIPA

2016-09-22 Thread bahan w 
Hello !

I contact you because I have a problem with a filer mounted on a server on
which I installed freeipa client.

I'm using FreeIPA 3.0.0-47 for both client and servers.

The filer is mounted on /myfiler
I have a user defined in freeipa : User1
I have a group defined in freeipa : Group1
I have another user defined in freeipa : User2
User2 belongs to group Group1.


Test 1 :
I create a folder Folder1 outside of the filer, in /usr for example.
/usr/folder1
I set the posix permissions 750 and owner = user1 and group=group1.
I connect with user2 and tries to read the content of the folder
/usr/folder1.
It works fine.

Test 2 :
I create a folder Folder2 inside the filer, in /myfiler for example.
/myfiler/folder2
I set the posix permissions 750 and owner = user1 and group=group1.
I connect with user2 and tries to read the content of the folder
/usr/folder1.
It does not work with the following error : permission denied.

Is there something to do from filer side to plugin with FreeIPA server ?

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] CA Fails to build Replica (w/External CA)

2016-09-22 Thread Korey Chapman 
On Thu, Sep 22, 2016 at 1:52 AM, Florence Blanc-Renaud  wrote:
> Hi Korey,
>
> I believe that you are hitting Dogtag issue #2255 [1]. The file /tmp/ca.p12
> probably doesn't contain the trust flags for some certificates.
> You can check by running
> pki pkcs12-cert-find --pkcs12-file /tmp/ca.p12 --pkcs12-password password
> and see if the output displays "Trust Flags: xxx" for all the certs.
>
> Flo.
>
> [1] https://fedorahosted.org/pki/ticket/2255
>
>
> On 09/21/2016 05:38 PM, Korey Chapman wrote:
>>
>> On Wed, Sep 21, 2016 at 6:47 AM, Tomas Krizek  wrote:
>>>
>>> On 09/21/2016 02:13 AM, Korey Chapman wrote:
>>>
>>> Hello list,
>>>
>>> I'm currently attempting to add a second CA server to our IPA cluster
>>> (all
>>> servers Centos 7.2 with IPA 4.2.0). However, it is failing no matter how
>>> I
>>> try to setup the CA (ipa-replica-install with --setup-ca or
>>> ipa-replica-install followed by ipa-ca-install). The only useful thing in
>>> the logs is an error about a missing key for "trust_flags" in the pki
>>> setup.
>>> Our infrastructure uses FreeIPA with an external CA.
>>>
>>> Any ideas/help would be greatly appreciated. Here are the logs snips from
>>> my
>>> most recent attempt:
>>>
>>> Command output snip from "ipa-replica-install
>>> /root/replica-info-auth-002.XXX.gpg --setup-ca"
>>> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
>>> 30
>>> seconds
>>>   [1/24]: creating certificate server user
>>>   [2/24]: configuring certificate server instance
>>> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure
>>> CA
>>> instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpYofMPt''
>>> returned non-zero exit status 1
>>> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the
>>> installation
>>> logs and the following files/directories for more information:
>>> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
>>> /var/log/pki-ca-install.log
>>> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
>>> /var/log/pki/pki-tomcat
>>>   [error] RuntimeError: CA configuration failed.
>>> Your system may be partly configured.
>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>
>>> ipa.ipapython.install.cli.install_tool(Replica): ERRORCA
>>> configuration
>>> failed
>>>
>>>
>>> Log snip from ipareplica-install.log:
>>>
>>> 2016-09-20T23:42:27Z DEBUG Starting external process
>>> 2016-09-20T23:42:27Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
>>> '/tmp/tmpYofMPt'
>>> 2016-09-20T23:42:31Z DEBUG Process finished, return code=1
>>> 2016-09-20T23:42:31Z DEBUG stdout=Log file:
>>> /var/log/pki/pki-ca-spawn.20160920234227.log
>>> Loading deployment configuration from /tmp/tmpYofMPt.
>>> Installing CA into /var/lib/pki/pki-tomcat.
>>> Storing deployment configuration into
>>> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
>>>
>>> Installation failed.
>>>
>>>
>>> 2016-09-20T23:42:31Z 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)
>>> Traceback (most recent call last):
>>>   File "/bin/pki", line 254, in 
>>> cli.execute(sys.argv)
>>>   File "/bin/pki", line 240, in execute
>>> module.execute(module_args)
>>>   File "/usr/lib/python2.7/site-packages/pki/cli/__init__.py", line 195,
>>> in
>>> execute
>>> module.execute(module_args)
>>>   File "/usr/lib/python2.7/site-packages/pki/cli/pkcs12.py", line 222, in
>>> execute
>>> trust_flags = cert_info['trust_flags']
>>> KeyError: 'trust_flags'
>>>
>>>
>>> --
>>> Korey
>>>
>>>
>>> Hi Korey,
>>>
>>> could you check if there is any more info in /var/log/pki/pki-ca-spawn
>>> log?
>>
>>
>> Nothing really useful I see in the spawn log:
>> 2016-09-20 23:42:31 pkispawn: DEBUG... Error Type:
>> CalledProcessError
>> 2016-09-20 23:42:31 pkispawn: DEBUG... Error Message:
>> Command '['pki', '-d', '/etc/pki/pki-tomcat/alias', '-C',
>> '/etc/pki/pki-tomcat/pfile', 'pkcs12-import', '--pkcs12-file',
>> '/tmp/ca.p12', '--pkcs12-password-file',
>> '/tmp/tmps5OOav/password.txt', '--no-user-certs']' returned non-zero
>> exit status 1
>> 2016-09-20 23:42:31 pkispawn: DEBUG...   File
>> "/usr/sbin/pkispawn", line 597, in main
>> rv = scriptlet.spawn(deployer)
>>   File
>> "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/security_databases.py",
>> line 104, in spawn
>> no_user_certs=True)
>>   File "/usr/lib/python2.7/site-packages/pki/nssdb.py", line 538, in
>> import_pkcs12
>> subprocess.check_call(cmd)
>>   File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call
>> raise CalledProcessError(retcode, cmd)
>>
>>>
>>> It might also be helpful verify if correct trust flags are set in nssdb:
>>> certutil -d

Re: [Freeipa-users] down master still in ldap, prevents re-enrolement

2016-09-22 Thread Rob Crittenden 

Petr Vobornik wrote:

On 09/21/2016 11:25 PM, pgb205 wrote:

topology prior to deletion

master1<->master2

master2 deleted with ipa-server --uninstall command

During re-installation I get error that the replication agreement still exists
on master1.
I do see this using ipa-replica-manage list.

Tried deleting replication agreement with
ipa-replica-manage disconnect but receive 'no such replication agreement exist'

Force deletion and cleanup do not work
receive unexpected error: Server is unwilling to perform: database is read-only


removing directly from ldap gives me:
   ldapdelete -r -x -D "cn=Directory Manager" -W
'cn=fqdn,cn=masters,cn=ipa,cn=etc,dc=domain,dc=com'
Enter LDAP Password:
ldap_delete: Server is unwilling to perform (53)
ldap_delete: Server is unwilling to perform (53)
  additional info: database is read-only

But I am not sure if I'm not using correct path or if it's something else.

Might be related to Bug 826677 – IPA cannot remove disconnected replica data to
reconnect 




 Bug 826677 – IPA cannot remove disconnected replica data to reconnect







run on master1:
  ipa-csreplica-manage del master2 --force --clean
  ipa-replica-manage del master2 --force --clean

In that order. First step only if master2 was installed with CA.

Those command should clean left-over data from master2.

In standard situation, recommended uninstallation procedure for IPAs
prior FreeIPA 4.4 is:
   master1# ipa-csreplica-manage del master2
   master1# ipa-replica-manage del master2
   master2# ipa-server-install --uninstall



Ultimately the problem is that the database is set to read only.

$ ldapsearch -x -D 'cn=directory manager' -W -s base -b 'cn=userRoot, 
cn=ldbm database, cn=plugins, cn=config' nsslapd-readonly


rob

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

Re: [Freeipa-users] down master still in ldap, prevents re-enrolement

2016-09-22 Thread Petr Vobornik 
On 09/21/2016 11:25 PM, pgb205 wrote:
> topology prior to deletion
> 
> master1<->master2
> 
> master2 deleted with ipa-server --uninstall command
> 
> During re-installation I get error that the replication agreement still 
> exists 
> on master1.
> I do see this using ipa-replica-manage list.
> 
> Tried deleting replication agreement with
> ipa-replica-manage disconnect but receive 'no such replication agreement 
> exist'
> 
> Force deletion and cleanup do not work
> receive unexpected error: Server is unwilling to perform: database is 
> read-only
> 
> 
> removing directly from ldap gives me:
>   ldapdelete -r -x -D "cn=Directory Manager" -W 
> 'cn=fqdn,cn=masters,cn=ipa,cn=etc,dc=domain,dc=com'
> Enter LDAP Password:
> ldap_delete: Server is unwilling to perform (53)
> ldap_delete: Server is unwilling to perform (53)
>  additional info: database is read-only
> 
> But I am not sure if I'm not using correct path or if it's something else.
> 
> Might be related to Bug 826677 – IPA cannot remove disconnected replica data 
> to 
> reconnect 
> 
>   
> 
> 
> Bug 826677 – IPA cannot remove disconnected replica data to reconnect
> 
>   
> 
> 
> 

run on master1:
 ipa-csreplica-manage del master2 --force --clean
 ipa-replica-manage del master2 --force --clean

In that order. First step only if master2 was installed with CA.

Those command should clean left-over data from master2.

In standard situation, recommended uninstallation procedure for IPAs
prior FreeIPA 4.4 is:
  master1# ipa-csreplica-manage del master2
  master1# ipa-replica-manage del master2
  master2# ipa-server-install --uninstall
-- 
Petr Vobornik

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

Re: [Freeipa-users] sssd.conf - the server and host-client relationship

2016-09-22 Thread Lukas Slebodnik 
On (22/09/16 08:53), Lachlan Musicman wrote:
>My translations of your comments are in line, if you could correct, I'd
>appreciate that.
>
>On 20 September 2016 at 17:11, Lukas Slebodnik  wrote:
>
>> >--
>> >[domain/unixdev.etc]
>> >ignore_group_members = True
>> It was probably set as a result of performance tuning.
>>
>> >ldap_purge_cache_timeout = 0
>> That's default since 1.13.0
>>
>> >subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
>> that's specific option for sssd on IPA server
>>
>
>
>I presume your comment suggests ignore_group_members is no longer needed,
>and since the lpct=0 is now default, then subdomain_inherit is also
>superfluous?
>
I have no idea why the option ignore_group_members was set.
My assumption is that you wanted to reduce loading data from IPA/AD
because they were many members in groups and it was slow.

>
>
>> >selinux_provider = none
>> It was probably set as a workaround of bug which have been already
>> fixed.
>>
>
>We set this because of an error in libsemanage, but I think that was an
>upstream (selinux) issue?
>https://www.redhat.com/archives/freeipa-users/2016-July/msg00244.html
>
>Not sure if I should disable just yet - was this fixed?
It should be fixed if not file a bug.

>>
>> >ipa_server_mode = True
>> that's specific option for sssd on IPA server
>>
>>
>I take it that this means it's still used.
>
yes, but it is used only on in sssd which is on IPA server.

>
>> >sudo_provider = ldap
>> >ldap_uri = ldap://vmdv-linuxidm1.unixdev.petermac.org.au
>> >ldap_sudo_search_base = or=sudoers,dc=unixdev,dc=petermac,dc=org,dc=au
>> >ldap_sasl_mech = GSSAPI
>> >ldap_sasl_authid = host/vmdv-linuxidm1.unixdev.petermac.org.au
>> >ldap_sasl_realm = UNIXDEV.PETERMAC.ORG.AU
>> >krb5_server = vmdv-linuxidm1.unixdev.petermac.org.au
>> Previous 7 options are not required since sssd-1.10
>>
>
>Yep, I added those because of disconnect between the different info sources
>made it hard to tell what was canonical, so I followed the red hat guide:
>
>https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html
>
>mostly because I didn't quite understand the sssd-sudo man page (because
>sometimes I find man pages obtuse), but also there was an inconsistency
>with the local man page and the die.net mirror
>https://linux.die.net/man/5/sssd-sudo and this howto
>https://blog-rcritten.rhcloud.com/?p=52
>
The best is to check version of man page sssd-sudo on the machine
But as I wrote "sudo_provider = ldap" is not required for ipa client
since sssd-1.10 and most of current distributions has newer version
of sssd.

LS

-- 
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] OT: slow NFS4 (kerberos) since moving to IPA

2016-09-22 Thread Torsten Harenberg 
Dear all,

please excuse, this is slightly off-topic.

We run an NFS4 server (running Ubuntu 14.04) serving about 40 clients on
(running Ubuntu and Mint as well as a few CentOS 6 nodes).

We moved all our infrastructure to IPA to have Kerberos security. File
systems are mounted with

home -fstype=nfs4,rw,sec=krb5i

using the automounter.

That all works fine.

Now the clients show timeouts in the system logs

physikd98kuech kernel: [  595.004026] nfs: server
whep-nfs.pleiades.uni-wuppertal.de not responding, still trying

and sometimes the NFS server has a

 whep-nfs kernel: [ 1129.628090] RPC: AUTH_GSS upcall failed. Please
check user daemon is running.

or

 whep-nfs rpc.gssd[462]: destroying client /run/rpc_pipefs/nfsd4_cb/clnt151

in their logs. We already increased the debug levels (for example of
idmapd) but haven't had anything obvious so far.

Surprisingly, we have three main "public login machines" running CentOS
6, they seem to run fine. So probably it's not a NFS server issue.

We increased the number of NFS server processes running on the NFS
server from the default 8 (which might be too little for a setup like
this) to 128. Also I upgraded the sssd on the server to 1.12.5 (compared
to the 1.11 which comes with Ubuntu).

All with little success, users are still complaining about the slow
connection.

Our munin monitoring shows no satuaration on the NFS server. The load is
also nearly 0. The real file system is mounted through a high-perfomance
FibreChannel system.

Any thoughts / ideas are appreciated.

Thanks

  Torsten


-- 
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<>  <>
<> Dr. Torsten Harenberg harenb...@physik.uni-wuppertal.de  <>
<> Bergische Universitaet   <>
<> FB C - Physik Tel.: +49 (0)202 439-3521  <>
<> Gaussstr. 20  Fax : +49 (0)202 439-2811  <>
<> 42097 Wuppertal  <>
<>  <>
<><><><><><><>< Of course it runs NetBSD http://www.netbsd.org ><>

-- 
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 Fails to build Replica (w/External CA)

2016-09-22 Thread Florence Blanc-Renaud 

Hi Korey,

I believe that you are hitting Dogtag issue #2255 [1]. The file 
/tmp/ca.p12 probably doesn't contain the trust flags for some certificates.

You can check by running
pki pkcs12-cert-find --pkcs12-file /tmp/ca.p12 --pkcs12-password password
and see if the output displays "Trust Flags: xxx" for all the certs.

Flo.

[1] https://fedorahosted.org/pki/ticket/2255

On 09/21/2016 05:38 PM, Korey Chapman wrote:

On Wed, Sep 21, 2016 at 6:47 AM, Tomas Krizek  wrote:

On 09/21/2016 02:13 AM, Korey Chapman wrote:

Hello list,

I'm currently attempting to add a second CA server to our IPA cluster (all
servers Centos 7.2 with IPA 4.2.0). However, it is failing no matter how I
try to setup the CA (ipa-replica-install with --setup-ca or
ipa-replica-install followed by ipa-ca-install). The only useful thing in
the logs is an error about a missing key for "trust_flags" in the pki setup.
Our infrastructure uses FreeIPA with an external CA.

Any ideas/help would be greatly appreciated. Here are the logs snips from my
most recent attempt:

Command output snip from "ipa-replica-install
/root/replica-info-auth-002.XXX.gpg --setup-ca"
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
seconds
  [1/24]: creating certificate server user
  [2/24]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA
instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpYofMPt''
returned non-zero exit status 1
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation
logs and the following files/directories for more information:
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki-ca-install.log
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki/pki-tomcat
  [error] RuntimeError: CA configuration failed.
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERRORCA configuration
failed


Log snip from ipareplica-install.log:

2016-09-20T23:42:27Z DEBUG Starting external process
2016-09-20T23:42:27Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
'/tmp/tmpYofMPt'
2016-09-20T23:42:31Z DEBUG Process finished, return code=1
2016-09-20T23:42:31Z DEBUG stdout=Log file:
/var/log/pki/pki-ca-spawn.20160920234227.log
Loading deployment configuration from /tmp/tmpYofMPt.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.

Installation failed.


2016-09-20T23:42:31Z 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)
Traceback (most recent call last):
  File "/bin/pki", line 254, in 
cli.execute(sys.argv)
  File "/bin/pki", line 240, in execute
module.execute(module_args)
  File "/usr/lib/python2.7/site-packages/pki/cli/__init__.py", line 195, in
execute
module.execute(module_args)
  File "/usr/lib/python2.7/site-packages/pki/cli/pkcs12.py", line 222, in
execute
trust_flags = cert_info['trust_flags']
KeyError: 'trust_flags'


--
Korey


Hi Korey,

could you check if there is any more info in /var/log/pki/pki-ca-spawn log?


Nothing really useful I see in the spawn log:
2016-09-20 23:42:31 pkispawn: DEBUG... Error Type:
CalledProcessError
2016-09-20 23:42:31 pkispawn: DEBUG... Error Message:
Command '['pki', '-d', '/etc/pki/pki-tomcat/alias', '-C',
'/etc/pki/pki-tomcat/pfile', 'pkcs12-import', '--pkcs12-file',
'/tmp/ca.p12', '--pkcs12-password-file',
'/tmp/tmps5OOav/password.txt', '--no-user-certs']' returned non-zero
exit status 1
2016-09-20 23:42:31 pkispawn: DEBUG...   File
"/usr/sbin/pkispawn", line 597, in main
rv = scriptlet.spawn(deployer)
  File 
"/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/security_databases.py",
line 104, in spawn
no_user_certs=True)
  File "/usr/lib/python2.7/site-packages/pki/nssdb.py", line 538, in
import_pkcs12
subprocess.check_call(cmd)
  File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call
raise CalledProcessError(retcode, cmd)



It might also be helpful verify if correct trust flags are set in nssdb:
certutil -d /etc/pki/pki-tomcat/alias/ -L



Run on the source ipa server (current CA server):
$ certutil -d /etc/pki/pki-tomcat/alias/ -L

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

XXX Certificate Authority CT,c,
Server-Cert cert-pki-ca  u,u,u
auditSigningCert cert-pki-ca u,u,Pu
caSigningCert cert-pki-ca

Re: [Freeipa-users] key + 2FA (password+OTP) is not working

2016-09-22 Thread Sumit Bose 
On Thu, Sep 22, 2016 at 08:17:21AM +, Deepak Dimri wrote:
> Hi All,
> 
> 
> I am trying hard to get my 2FA working with FreeIPA but every effort of mine 
> going waste! I have referred earlier forum emails but could not find any good 
> reply on the issue i am facing.
> 
> 
> This is what i am trying
> 
> 
> I have a test user created in my IPA server enabled with Two factor 
> authentication (password + OTP) and has ssh public key added in its profile.  
> I want this test user to ssh into my ipa client (ubuntu 14.04) using  key + 
> password + OTP. I woudl ceryainly prefer just the key+  OTP only ( no 
> password) but that seems far sighted as i cannot even make it work with what 
> it supposed to work password + OTP.
> 
> 
> My /etc/ssh/sshd_conf file has almost everything default  except i added 
> these two lines at the end of it
> 
> Match Group testusergroup
> 
>AuthenticationMethods publickey,password:pam 
> publickey,keyboard-interactive:pam
> 
> i also tried with below but no luck
> 
> Match Group testusergroup
> 
>  AuthenticationMethods publickey,keyboard-interactive
> 
> 
> my /etc/pam.d/sshd has these two changes, rest i kept default:
> 
> 
> # Standard Un*x authentication.
> 
> #@include common-auth
> 
> 
> auth required pam_sss.so
> 
> 
> Now when i try to ssh into ipa client i either keep getting promptS for the 
> password or it gets into a loop asking me to change the password ;complaining 
> falsely that it has expired. I have tried multiple combinations of 
> configurations by referring earlier email threads but none i found helpful. I 
> cant make simple 2FA login to work with freeIPA. Normal password and key 
> works just fine. its the 2FA which does not work for me.
> 
> 
> Would really be thankful if some one can help me with this issue.. is there 
> any good freeIPA 2FA configuration document that i can refer?

Please add debug_level=10 to the [pam] and [domain/...] section of
sssd.conf, restart SSSD, re-run the authentication and send the
generated debug logs together with your sssd.conf and the full
/etc/pam.d/sshd. Please see
https://fedorahosted.org/sssd/wiki/Troubleshooting for details.

> 
> What should the steps for it work seamlessly?

In general it should work out of the box with SSSD's ipa provider.

bye,
Sumit

> 
> 
> Many Thanks,
> 
> Deepak
> 

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

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

[Freeipa-users] key + 2FA (password+OTP) is not working

2016-09-22 Thread Deepak Dimri 
Hi All,


I am trying hard to get my 2FA working with FreeIPA but every effort of mine 
going waste! I have referred earlier forum emails but could not find any good 
reply on the issue i am facing.


This is what i am trying


I have a test user created in my IPA server enabled with Two factor 
authentication (password + OTP) and has ssh public key added in its profile.  I 
want this test user to ssh into my ipa client (ubuntu 14.04) using  key + 
password + OTP. I woudl ceryainly prefer just the key+  OTP only ( no password) 
but that seems far sighted as i cannot even make it work with what it supposed 
to work password + OTP.


My /etc/ssh/sshd_conf file has almost everything default  except i added these 
two lines at the end of it

Match Group testusergroup

   AuthenticationMethods publickey,password:pam 
publickey,keyboard-interactive:pam

i also tried with below but no luck

Match Group testusergroup

 AuthenticationMethods publickey,keyboard-interactive


my /etc/pam.d/sshd has these two changes, rest i kept default:


# Standard Un*x authentication.

#@include common-auth


auth required pam_sss.so


Now when i try to ssh into ipa client i either keep getting promptS for the 
password or it gets into a loop asking me to change the password ;complaining 
falsely that it has expired. I have tried multiple combinations of 
configurations by referring earlier email threads but none i found helpful. I 
cant make simple 2FA login to work with freeIPA. Normal password and key works 
just fine. its the 2FA which does not work for me.


Would really be thankful if some one can help me with this issue.. is there any 
good freeIPA 2FA configuration document that i can refer?

What should the steps for it work seamlessly?


Many Thanks,

Deepak

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

Re: [Freeipa-users] replica added, but clients still try renewing certificates with old master

2016-09-22 Thread Natxo Asenjo 
On Wed, Sep 21, 2016 at 5:06 PM, Natxo Asenjo 
wrote:

> ok, done.
>
> In fact, change both the domain as the xmlrpc_uri directives in the global
> section was necessary. Now It worked :-)
>

I meant the server, not the domain options obviously.

--
Groeten,
natxo
-- 
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