[Freeipa-users] Re: Export service keytab as Active Directory user

2018-11-27 Thread Michael Gusek via FreeIPA-users 
Hi Alexander,

the main reason for us was that AD user can export keytab files for
their managed services. With current FreeIPA it's not possible, so the
admin team will do the job.

Thx for linking to documentation for RedHat 8, this is what we want (in
the future).

Greetings,

Micha


Am 26.11.18 um 09:58 schrieb Alexander Bokovoy:
> On ma, 26 marras 2018, Michael Gusek via FreeIPA-users wrote:
>> Thx a lot. So we will export keytabs for our AD users.
> Sorry, how this would help? Your real issue is that you cannot assign
> group membership in LDAP to AD users, this is where access rights are
> checked.
>
> You can read a basic explanation at
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/installing_identity_management_and_access_control/enabling-ad-user-to-administer-idm-fin-fin
>
>
> or more details at https://github.com/abbra/freeipa-adusers-admins
>
>>
>> Micha
>>
>>
>> Am 23.11.18 um 16:25 schrieb Alexander Bokovoy via FreeIPA-users:
>>> Not possible in centos 7.
>>>
>>> Possible in RHEL8 beta.
>>>
>>> (Sorry for being short, I'm on the phone)
>>>
>>> - Michael Gusek via FreeIPA-users
>>>  wrote:
>>>> Hi,
>>>>
>>>> we are running FreeIPA 4.5.4 on Centos 7 with a one way trust to an
>>>> Active Directory. We want to allow AD users to retrieve service keytab
>>>> on FreeIPA managed hosts. AD users are linked to a external group, and
>>>> these group to a FreeIPA group.  We've created a service and allowed
>>>> FreeIPA group (for testing external group too) to retrieve keytab. Now
>>>> we logged in with AD credentials to a FreeIPA managed host, got an
>>>> ticket with kinit user@AD-domain and tried to retrieve keytab for
>>>> service, which runs in an error "Failed to parse result: Insufficient
>>>> access rights". With an FreeIPA user, added to FreeIPA group above, it
>>>> works.
>>>>
>>>> So what we are missing here ? Is it possible to retrieve service
>>>> keytabs
>>>> as a trusted AD user ?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> ___
>>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>>> To unsubscribe send an email to
>>>> freeipa-users-le...@lists.fedorahosted.org
>>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>>> List Guidelines:
>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> List Archives:
>>>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>> -- 
>>
>> 
>>
>>
>> *Michael**Gusek*| System Administrator| Webtrekk GmbH |
>> *t*+49 30 755 415 302| *f *+49 30 755 415 100 | *w *www.webtrekk.com
>> <https://www.webtrekk.com/?wt_mc=signature.-.-.-.homepageURL>
>> Amtsgericht/Local Court Berlin, HRB 93435 B | Geschäftsführer/CEO
>> Christian Sauer und Norman Wahnschaff
>>
>>
>
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to
>> freeipa-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>
>
-- 




*Michael**Gusek*| System Administrator| Webtrekk GmbH |
*t*+49 30 755 415 302| *f *+49 30 755 415 100 | *w *www.webtrekk.com
<https://www.webtrekk.com/?wt_mc=signature.-.-.-.homepageURL>
Amtsgericht/Local Court Berlin, HRB 93435 B | Geschäftsführer/CEO
Christian Sauer und Norman Wahnschaff


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Export service keytab as Active Directory user

2018-11-26 Thread Michael Gusek via FreeIPA-users 
Thx a lot. So we will export keytabs for our AD users.

Micha


Am 23.11.18 um 16:25 schrieb Alexander Bokovoy via FreeIPA-users:
> Not possible in centos 7.
>
> Possible in RHEL8 beta.
>
> (Sorry for being short, I'm on the phone)
>
> ----- Michael Gusek via FreeIPA-users  
> wrote:
>> Hi,
>>
>> we are running FreeIPA 4.5.4 on Centos 7 with a one way trust to an
>> Active Directory. We want to allow AD users to retrieve service keytab
>> on FreeIPA managed hosts. AD users are linked to a external group, and
>> these group to a FreeIPA group.  We've created a service and allowed
>> FreeIPA group (for testing external group too) to retrieve keytab. Now
>> we logged in with AD credentials to a FreeIPA managed host, got an
>> ticket with kinit user@AD-domain and tried to retrieve keytab for
>> service, which runs in an error "Failed to parse result: Insufficient
>> access rights". With an FreeIPA user, added to FreeIPA group above, it
>> works.
>>
>> So what we are missing here ? Is it possible to retrieve service keytabs
>> as a trusted AD user ?
>>
>> Thanks.
>>
>>
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
-- 




*Michael**Gusek*| System Administrator| Webtrekk GmbH |
*t*+49 30 755 415 302| *f *+49 30 755 415 100 | *w *www.webtrekk.com
<https://www.webtrekk.com/?wt_mc=signature.-.-.-.homepageURL>
Amtsgericht/Local Court Berlin, HRB 93435 B | Geschäftsführer/CEO
Christian Sauer und Norman Wahnschaff


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Export service keytab as Active Directory user

2018-11-23 Thread Michael Gusek via FreeIPA-users 
Hi,

we are running FreeIPA 4.5.4 on Centos 7 with a one way trust to an
Active Directory. We want to allow AD users to retrieve service keytab
on FreeIPA managed hosts. AD users are linked to a external group, and
these group to a FreeIPA group.  We've created a service and allowed
FreeIPA group (for testing external group too) to retrieve keytab. Now
we logged in with AD credentials to a FreeIPA managed host, got an
ticket with kinit user@AD-domain and tried to retrieve keytab for
service, which runs in an error "Failed to parse result: Insufficient
access rights". With an FreeIPA user, added to FreeIPA group above, it
works.

So what we are missing here ? Is it possible to retrieve service keytabs
as a trusted AD user ?

Thanks.


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: AD overwrite not persistence

2018-07-03 Thread Michael Gusek via FreeIPA-users 
Ok, i've activated logging for all sections, i'm missed section nss. I
will upload log files next time if i run in trouble.

Michael


Am 03.07.2018 um 15:49 schrieb Alexander Bokovoy:
> On ti, 03 heinä 2018, Michael Gusek via FreeIPA-users wrote:
>> Hi Alexander,
>>
>> its SSSD, we check it with id -u u...@example.com.
> Then you need to gather logs from SSSD on IPA master.
> Basically, add
>
> debug_level = 9
>
> in domain and nss sections to /etc/sssd/sssd.conf and restart sssd.
>
> Logs will be large so it would be good to gather them and put somewhere.
>
> General troubleshooting notes apply:
> https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

-- 




*Michael**Gusek*| System Administrator| Webtrekk GmbH |
*t*+49 30 755 415 302| *f *+49 30 755 415 100 | *w *www.webtrekk.com
<https://www.webtrekk.com/?wt_mc=signature.-.-.-.homepageURL>
Amtsgericht/Local Court Berlin, HRB 93435 B | Geschäftsführer/CEO
Christian Sauer und Norman Wahnschaff


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/SEGXVFZFOVY2JW7NG5F5CC6MKGCUSRSZ/

[Freeipa-users] Re: AD overwrite not persistence

2018-07-03 Thread Michael Gusek via FreeIPA-users 
Hi Alexander,

its SSSD, we check it with id -u u...@example.com.

Michael


Am 03.07.2018 um 14:57 schrieb Alexander Bokovoy via FreeIPA-users:
> On ti, 03 heinä 2018, Michael Gusek via FreeIPA-users wrote:
>> Hi,
>>
>> we use an Active Directory (Server 2012) and a FreeIPA 4.5.4
>> installation. FreeIPA runs under Centos 7, sssd version is
>> sssd-1.16.0-19.el7.x86_64. Between AD and FreeIPA we have set up a
>> one-way trust. For some AD users, we have set up a uid override under
>> "Default Trust View" in FreeIPA. This overwrite is regularly lost on the
>> FreeIPA server. If we clear the sssd cache (systemctl stop sssd; rm -rf
>> /var/lib/sss/{db,mc}/*; systemctl start sssd), the override takes effect
>> again. Here is a history for today:
>>
>> 2018-07-03 10:55:01
>> 2018-07-03 11:05:01
>> 2018-07-03 11:06:01
>> 2018-07-03 11:10:01
>> 2018-07-03 11:12:01
>> 2018-07-03 11:15:01
>> 2018-07-03 11:29:01
>> 2018-07-03 11:31:01
>> 2018-07-03 11:34:01
>>
>> As you can see, there is no periodicality, from yesterday to today it
>> runs for about 11h without problems, and today since 11:34
>>
>> How can fix the problem?
> It is unclear from your explanation where is the override lost. Is it
> that LDAP entry for the override disappears? Or is it SSSD that is
> forgetting an override?
>
>



___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/VTWMP4FTUGZWUBWLTHA27OY6ZQTHWISE/

[Freeipa-users] AD overwrite not persistence

2018-07-03 Thread Michael Gusek via FreeIPA-users 
Hi,

we use an Active Directory (Server 2012) and a FreeIPA 4.5.4
installation. FreeIPA runs under Centos 7, sssd version is
sssd-1.16.0-19.el7.x86_64. Between AD and FreeIPA we have set up a
one-way trust. For some AD users, we have set up a uid override under
"Default Trust View" in FreeIPA. This overwrite is regularly lost on the
FreeIPA server. If we clear the sssd cache (systemctl stop sssd; rm -rf
/var/lib/sss/{db,mc}/*; systemctl start sssd), the override takes effect
again. Here is a history for today:

2018-07-03 10:55:01
2018-07-03 11:05:01
2018-07-03 11:06:01
2018-07-03 11:10:01
2018-07-03 11:12:01
2018-07-03 11:15:01
2018-07-03 11:29:01
2018-07-03 11:31:01
2018-07-03 11:34:01

As you can see, there is no periodicality, from yesterday to today it
runs for about 11h without problems, and today since 11:34

How can fix the problem?

Michael



___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/T55Y4KCXR5OIZITBIAWQ3T3PAF36QSQE/

[Freeipa-users] Re: sudo not working with hostgroups

2017-09-29 Thread Michael Gusek via FreeIPA-users 
Anybody have an idea for me?

Michael


Am 22.09.2017 um 10:50 schrieb Michael Gusek via FreeIPA-users:
>
> Hello,
>
> we are using FreeIPA in the current version 4.5 under current CentOS
> 7. In order to grant access we are using sudo rules in conjunction
> with host groups. We have found that these rules do not work under
> Debian 8/9 and Ubuntu 16.04, but with Centos 6/7. Suggestions from the
> web require a set nisdomainname (nisdomainname example.com), which
> does not work. In fact, the nisdomainname is not set under CentOS 6,
> but under Centos 7 it is. What settings under Debian/Ubuntu must be
> made for sudo rules to work with hostgroups?
>
>
>   Debian 8Debian 9Ubuntu 16.04Centos 6Centos 7
> sssd-Version  1.15.0-31.15.0-3
> 1.15.0-3ubuntu2~ubuntu16.04.1~ppa1
> sssd-1.15.3-1.el6.x86_64  sssd-1.15.2-50.el7_4.2.x86_64
> sudo-Version  1.8.10p3-1+deb8u4   1.8.19p1-2.11.8.16-0ubuntu1.5
> sudo-1.8.6p3-29.el6_9.x86_64  sudo-1.8.19p2-11.el7_4.x86_64
>
> Regards,
>
> Michael
>
> ​
> -- 
>
> 
>
>
> *Michael**Gusek*| System Administrator| Webtrekk GmbH |
> *t*+49 30 755 415 302| *f *+49 30 755 415 100 | *w *www.webtrekk.com
> <https://www.webtrekk.com/?wt_mc=signature.-.-.-.homepageURL>
> Amtsgericht/Local Court Berlin, HRB 93435 B | Geschäftsführer/CEO
> Christian Sauer und Wolf Lichtenstein
>
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

-- 




*Michael**Gusek*| System Administrator| Webtrekk GmbH |
*t*+49 30 755 415 302| *f *+49 30 755 415 100 | *w *www.webtrekk.com
<https://www.webtrekk.com/?wt_mc=signature.-.-.-.homepageURL>
Amtsgericht/Local Court Berlin, HRB 93435 B | Geschäftsführer/CEO
Christian Sauer und Wolf Lichtenstein


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA failover not working

2017-08-31 Thread Michael Gusek via FreeIPA-users 
Hi,

just for info. We restart our setup on an other stage in our dc with
same result, we run in timeouts if first installed ipa server not
available. So we give it a try in a complete different environment, with
successfully failover. It  seem's we have a problem in our dc and we
will have a deeper look on our environment.

Thanks,

Michael


Am 24.08.2017 um 21:12 schrieb Jakub Hrozek via FreeIPA-users:
> On Thu, Aug 24, 2017 at 10:12:55AM +0200, Michael Gusek via FreeIPA-users 
> wrote:
>> Hello Jakub,
>>
>> here the first lines of ldap_child.log
>>
>> |(Wed Aug 23 16:07:11 2017) [[sssd[ldap_child[2104 [main] (0x0400):
>> ldap_child started. (Wed Aug 23 16:07:11 2017)
>> [[sssd[ldap_child[2104 [main] (0x2000): context initialized (Wed Aug
>> 23 16:07:11 2017) [[sssd[ldap_child[2104 [unpack_buffer] (0x1000):
>> total buffer size: 81 (Wed Aug 23 16:07:11 2017)
>> [[sssd[ldap_child[2104 [unpack_buffer] (0x1000): realm_str size: 16
>> (Wed Aug 23 16:07:11 2017) [[sssd[ldap_child[2104 [unpack_buffer]
>> (0x1000): got realm_str: IPA.EXAMPLE.COM (Wed Aug 23 16:07:11 2017)
>> [[sssd[ldap_child[2104 [unpack_buffer] (0x1000): princ_str size: 41
>> (Wed Aug 23 16:07:11 2017) [[sssd[ldap_child[2104 [unpack_buffer]
>> (0x1000): got princ_str: host/ipa-lx-test-debian9.ípa.example.com (Wed
>> Aug 23 16:07:11 2017) [[sssd[ldap_child[2104 [unpack_buffer]
>> (0x1000): keytab_name size: 0 (Wed Aug 23 16:07:11 2017)
>> [[sssd[ldap_child[2104 [unpack_buffer] (0x1000): lifetime: 86400
>> (Wed Aug 23 16:07:11 2017) [[sssd[ldap_child[2104 [unpack_buffer]
>> (0x0200): Will run as [0][0]. (Wed Aug 23 16:07:11 2017)
>> [[sssd[ldap_child[2104 [privileged_krb5_setup] (0x2000): Kerberos
>> context initialized (Wed Aug 23 16:07:11 2017)
>> [[sssd[ldap_child[2104 [main] (0x2000): Kerberos context initialized
>> (Wed Aug 23 16:07:11 2017) [[sssd[ldap_child[2104 [become_user]
>> (0x0200): Trying to become user [0][0]. (Wed Aug 23 16:07:11 2017)
>> [[sssd[ldap_child[2104 [become_user] (0x0200): Already user [0].
>> (Wed Aug 23 16:07:11 2017) [[sssd[ldap_child[2104 [main] (0x2000):
>> Running as [0][0]. (Wed Aug 23 16:07:11 2017) [[sssd[ldap_child[2104
>> [main] (0x2000): getting TGT sync (Wed Aug 23 16:07:11 2017)
>> [[sssd[ldap_child[2104 [ldap_child_get_tgt_sync] (0x2000): got
>> realm_name: [IPA.EXAMPLE.COM] (Wed Aug 23 16:07:11 2017)
>> [[sssd[ldap_child[2104 [ldap_child_get_tgt_sync] (0x0100): Principal
>> name is: [host/ipa-lx-test-debian9.ípa.example@ipa.example.com] (Wed
>> Aug 23 16:07:11 2017) [[sssd[ldap_child[2104
>> [ldap_child_get_tgt_sync] (0x0100): Using keytab
>> [MEMORY:/etc/krb5.keytab] (Wed Aug 23 16:07:11 2017)
>> [[sssd[ldap_child[2104 [ldap_child_get_tgt_sync] (0x0100): Will
>> canonicalize principals (Wed Aug 23 16:07:11 2017)
>> [[sssd[ldap_child[2104 [sss_child_krb5_trace_cb] (0x4000): [2104]
>> 1503497231.122092: Getting initial credentials for
>> host/ipa-lx-test-debian9.ípa.example@ipa.example.com (Wed Aug 23
>> 16:07:11 2017) [[sssd[ldap_child[2104 [sss_child_krb5_trace_cb]
>> (0x4000): [2104] 1503497231.122313: Looked up etypes in keytab:
>> aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1,
>> rc4-hmac (Wed Aug 23 16:07:11 2017) [[sssd[ldap_child[2104
>> [sss_child_krb5_trace_cb] (0x4000): [2104] 1503497231.122451: Sending
>> request (218 bytes) to IPA.EXAMPLE.COM (Wed Aug 23 16:07:17 2017)
>> [[sssd[ldap_child[2104 [sig_term_handler] (0x0010): Received signal
>> [Terminated] [15], shutting down (Wed Aug 23 16:07:17 2017)
>> [[sssd[ldap_child[2104 [sig_term_handler] (0x0010): Unlink file
>> [/var/lib/sss/db/ccache_IPA.EXAMPLE.COM_TmKHkD] (Wed Aug 23 16:07:17
>> 2017) [[sssd[ldap_child[2105 [main] (0x0400): ldap_child started.
>> (Wed Aug 23 16:07:17 2017) [[sssd[ldap_child[2105 [main] (0x2000):
>> context initialized |
>>
>> We connect to IPA.EXAMPLE.COM, this is not helpfull. You can see, there
>> is a delay of 5 seconds. Later in this file, you can see, we try to
>> connect to second server ipa-lx-test-02.ípa.example.com.
> Right, sssd says it does, but I really wonder why the ldap_child
> timeouts even in that case. Are there any log entries in the
> ipa-lx-test-02.ípa.example.com's log files around the time sssd connects
> to it?
>
> And also -- could you run a simple tcpdump (tcpdump -i eth1 -x "port
> 88 or port 53") to see what hosts does sssd talk to and what hosts does
> it discover?
>
> What I'm wondering is -- does SSSD really talk to the right server at
> that tim

[Freeipa-users] Re: FreeIPA failover not working

2017-08-24 Thread Michael Gusek via FreeIPA-users 
/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm =
IPA.EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true rdns =
false ticket_lifetime = 24h forwardable = yes default_ccache_name =
KEYRING:persistent:%{uid} [realms] IPA.EXAMPLE.COM = { pkinit_anchors =
FILE:/etc/ipa/ca.crt } [domain_realm] .ipa.example.com = IPA.EXAMPLE.COM
ipa.example.com = IPA.EXAMPLE.COM |

Regards,

Michael

Am 23.08.2017 um 22:20 schrieb Jakub Hrozek via FreeIPA-users:

> On Wed, Aug 23, 2017 at 05:13:13PM +0200, Michael Gusek via FreeIPA-users 
> wrote:
>> Hi,
>>
>> we are testing a FreeIPA trust to an Active Directory. Trust itself
>> works, we are happy. Now we tested a failure on FreeIPA site. We have
>> two instances, both with same roles. If we poweroff first installed
>> server, and clean sssd caches with restart of sssd on client side , sssd
>> service can’t establish a connection to second instance.
>>
>> ipa-lx-test-01.ipa.example.com is the first installed FreeIPA with
>> ipa-server-4.4.0-14.el7.centos.7.x86_64 on latest CentOS7
>> ipa-lx-test-02.ipa.example.com is the second installed FreeIPA with
>> ipa-server-4.4.0-14.el7.centos.7.x86_64 on latest CentOS7
>> ipa-lx-test-debian9.ipa.example.com is a latest Debian 9.1 with sssd
>> 1.15.0-3
>>
>> For deeper inspection full log is attached. In logs we found something
>> like this:
> OK, so as you say communication with the KDC failed:
> (Wed Aug 23 16:07:11 2017) [sssd[be[ipa.example.com]]] 
> [be_resolve_server_process] (0x0200): Found address for server 
> ipa-lx-test-02.ipa.example.com: [x.x.x.x] TTL 1200
>
> (Wed Aug 23 16:07:11 2017) [sssd[be[ipa.example.com]]] 
> [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT...
>   
> (Wed Aug 23 16:07:11 2017) [sssd[be[ipa.example.com]]] 
> [create_tgt_req_send_buffer] (0x0400): buffer size: 81
>   
> (Wed Aug 23 16:07:11 2017) [sssd[be[ipa.example.com]]] [child_handler_setup] 
> (0x2000): Setting up signal handler up for pid [2104] 
> 
> (Wed Aug 23 16:07:11 2017) [sssd[be[ipa.example.com]]] [child_handler_setup] 
> (0x2000): Signal handler set up for pid [2104]
> 
> (Wed Aug 23 16:07:11 2017) [sssd[be[ipa.example.com]]] 
> [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child 
>   
> (Wed Aug 23 16:07:11 2017) [sssd[be[ipa.example.com]]] [sdap_process_result] 
> (0x2000): Trace: sh[0x558252c35750], connected[1], ops[(nil)], 
> ldap[0x558252c130c0]   
> (Wed Aug 23 16:07:11 2017) [sssd[be[ipa.example.com]]] [sdap_process_result] 
> (0x2000): Trace: end of ldap_result list  
> 
> (Wed Aug 23 16:07:11 2017) [sssd[be[ipa.example.com]]] [write_pipe_handler] 
> (0x0400): All data has been sent! 
>  
> (Wed Aug 23 16:07:17 2017) [sssd[be[ipa.example.com]]] 
> [get_tgt_timeout_handler] (0x4000): timeout for sending SIGTERM to tgt child 
> [2104] reached.
> (Wed Aug 23 16:07:17 2017) [sssd[be[ipa.example.com]]] 
> [get_tgt_timeout_handler] (0x0400): Setting 2 seconds timeout for sending 
> SIGKILL to tgt child  
> (Wed Aug 23 16:07:17 2017) [sssd[be[ipa.example.com]]] [read_pipe_handler] 
> (0x0400): EOF received, client finished   
>   
> (Wed Aug 23 16:07:17 2017) [sssd[be[ipa.example.com]]] [child_sig_handler] 
> (0x1000): Waiting for child [2104].   
>   
> (Wed Aug 23 16:07:17 2017) [sssd[be[ipa.example.com]]] [child_sig_handler] 
> (0x0020): child [2104] failed with status [7].
>   
> (Wed Aug 23 16:07:17 2017) [sssd[be[ipa.example.com]]] [child_callback] 
> (0x0020): LDAP child was terminated due to timeout
>  
> (Wed Aug 23 16:07:17 2017) [sssd[be[ipa.example.com]]] [sdap_kinit_done] 
> (0x0080): Communic

[Freeipa-users] Re: AD-Trust users not known

2017-08-18 Thread Michael Gusek via FreeIPA-users 
Hello Jakub,

with my first tries i'v had following entries in /etc/sss/sssd.conf on
server side:

[sssd]
services = nss, sudo, pam, ssh
default_domain_suffix = example.com
full_name_format = %1$s
domains = ipa.example.com
debug_level = 10

With writing my first mail, i've disabled  'default_domain_suffix' and
'full_name_format', with no success on ipa-member.

In the meanwhile, i did some test's on ipa-member:

ipa-member> systemctl restart sssd
ipa-member> sss_cache -E
ipa-member> systemctl restart sssd
ipa-member> id usern...@example.com
uid=299801104(usern...@example.com) gid=299801104(usern...@example.com)
Gruppen=299801104(usern...@example.com),299800513(domänen-benut...@example.com),299801109(mitarbei...@example.com),55688(ad_us...@example.com)

So it work's as expected. Now i've enabled 'default_domain_suffix' and
'full_name_format' on server's sssd.conf, restart sssd and run
sss_cache. It's still working. I'm not sure, if 'sss_cache' does some
magical things. I will setup an other ipa client and test behavior on it.

Thanks,

Michael


Am 18.08.2017 um 12:07 schrieb Jakub Hrozek via FreeIPA-users:
> On Fri, Aug 18, 2017 at 12:00:45PM +0200, Michael Gusek via FreeIPA-users 
> wrote:
>> Hi,
>>
>> for testing i've installed an FreeIPA-Server with a trust to an
>> AD-Server. On IdM i can resolve AD-users with 'id usern...@example.com',
>> on IdM member client not.
>>
>> AD-Domain is Server 2012R2 as 'example.com'
>> IdM is latest CentOS 7 with ipa-server-4.4.0-14.el7.centos.7.x86_64 as
>> 'ipa.example.com'
>> IdM member client is latest CentOS 7 with
>> sssd-client-1.14.0-43.el7_3.18.x86_64
>>
>> Here an example on an Centos 7 client:
>> ipa-member> id usern...@example.com
>> id: 'usern...@example.com': no such user
>>
>> Logmessages, with log_level=10, shows:
>> ipa-member> tail -f /var/log/sssd/sssd_ipa.example.com.log | grep s2n
>> (Fri Aug 18 11:38:08 2017) [sssd[be[ipa.example.com]]]
>> [ipa_s2n_exop_send] (0x0400): Executing extended operation
>> (Fri Aug 18 11:38:08 2017) [sssd[be[ipa.example.com]]]
>> [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 13
>> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
>> [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result:
>> Success(0), (null).
>> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
>> [ipa_s2n_exop_send] (0x0400): Executing extended operation
>> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
>> [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 14
>> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
>> [ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: No such
>> object(32), (null).
>> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
>> [ipa_s2n_get_fqlist_next] (0x0040): s2n exop request failed.
>> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
>> [ipa_s2n_get_fqlist_done] (0x0040): s2n get_fqlist request failed.
>>
>> Running on IdM:
>> ipa-server> id usern...@example.com
>> uid=299801104(username) gid=299801104(username)
>> Gruppen=299801104(username),299800513(domänen-benutzer),299801109(mitarbeiter),55688(ad_users)
> The s2n operation triggers, through a DS plugin on the IPA side, a
> lookup through the SSSD NSS interface. So, tailing the sssd_nss logs
> on the server would be a good start to make sure all the NSS operations
> succeed.
>
> By the way, the name resolution of the users from the trusted domain
> does not include the domain name, just the username. How is that? Are
> you sure you're not using some hacks like full_name_format = $1 on the
> server side?
>
>> Any help is welcome.
>>
>> Michael
>>
>> - /etc/sssd.conf on ipa-member -
>> [domain/ipa.example.com]
>>
>> cache_credentials = True
>> krb5_store_password_if_offline = True
>> ipa_domain = ipa.example.com
>> id_provider = ipa
>> auth_provider = ipa
>> access_provider = ipa
>> ipa_hostname = ipa-server.ipa.example.com
>> chpass_provider = ipa
>> dyndns_update = True
>> ipa_server = _srv_, ipa-server.ipa.example.com
>> dyndns_iface = eth0
>> ldap_tls_cacert = /etc/ipa/ca.crt
>> debug_level = 10
>>
>> [sssd]
>> debug_level = 10
>> services = nss, sudo, pam, ssh
>> domains = ipa.example.com
>>
>> [nss]
>> debug_level = 10
>> homedir_substring = /home
>>
>> [pam]
>> debug_level = 10
>>
>> [sudo]
>>
>> [autofs]
>>
>> [ssh]
>>
>> [pac]
>> debug_level = 10
>>
>> [ifp]
>>
>> - /etc/sssd.conf on ipa

[Freeipa-users] AD-Trust users not known

2017-08-18 Thread Michael Gusek via FreeIPA-users 
Hi,

for testing i've installed an FreeIPA-Server with a trust to an
AD-Server. On IdM i can resolve AD-users with 'id usern...@example.com',
on IdM member client not.

AD-Domain is Server 2012R2 as 'example.com'
IdM is latest CentOS 7 with ipa-server-4.4.0-14.el7.centos.7.x86_64 as
'ipa.example.com'
IdM member client is latest CentOS 7 with
sssd-client-1.14.0-43.el7_3.18.x86_64

Here an example on an Centos 7 client:
ipa-member> id usern...@example.com
id: 'usern...@example.com': no such user

Logmessages, with log_level=10, shows:
ipa-member> tail -f /var/log/sssd/sssd_ipa.example.com.log | grep s2n
(Fri Aug 18 11:38:08 2017) [sssd[be[ipa.example.com]]]
[ipa_s2n_exop_send] (0x0400): Executing extended operation
(Fri Aug 18 11:38:08 2017) [sssd[be[ipa.example.com]]]
[ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 13
(Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
[ipa_s2n_exop_done] (0x0400): ldap_extended_operation result:
Success(0), (null).
(Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
[ipa_s2n_exop_send] (0x0400): Executing extended operation
(Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
[ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 14
(Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
[ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: No such
object(32), (null).
(Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
[ipa_s2n_get_fqlist_next] (0x0040): s2n exop request failed.
(Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]]
[ipa_s2n_get_fqlist_done] (0x0040): s2n get_fqlist request failed.

Running on IdM:
ipa-server> id usern...@example.com
uid=299801104(username) gid=299801104(username)
Gruppen=299801104(username),299800513(domänen-benutzer),299801109(mitarbeiter),55688(ad_users)

Any help is welcome.

Michael

- /etc/sssd.conf on ipa-member -
[domain/ipa.example.com]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ipa-server.ipa.example.com
chpass_provider = ipa
dyndns_update = True
ipa_server = _srv_, ipa-server.ipa.example.com
dyndns_iface = eth0
ldap_tls_cacert = /etc/ipa/ca.crt
debug_level = 10

[sssd]
debug_level = 10
services = nss, sudo, pam, ssh
domains = ipa.example.com

[nss]
debug_level = 10
homedir_substring = /home

[pam]
debug_level = 10

[sudo]

[autofs]

[ssh]

[pac]
debug_level = 10

[ifp]

- /etc/sssd.conf on ipa-server -
[domain/ipa.example.com]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ipa-server.ipa.example.com
chpass_provider = ipa
ipa_server = ipa-server.ipa.example.com
chpass_provider = ipa
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
subdomain_homedir = /home/%u
shell_fallback = /bin/bash
debug_level = 10

[sssd]
services = nss, sudo, pam, ssh
domains = ipa.example.com

[nss]
memcache_timeout = 600
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]


- complete log messages for 'id usern...@example.com' on ipa-member
-
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]]
[sysdb_search_user_by_upn] (0x0400): No entry with upn
[usern...@example.com] found.
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]]
[ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending
request
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]] [dp_req_done]
(0x0400): DP Request [Account #5]: Request handler finished [0]: Erfolg
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]] [_dp_req_recv]
(0x0400): DP Request [Account #5]: Receiving request data.
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]]
[dp_req_reply_list_success] (0x0400): DP Request [Account #5]: Finished.
Success.
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]]
[dp_req_reply_std] (0x1000): DP Request [Account #5]: Returning
[Success]: 0,0,Success
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]]
[dp_table_value_destructor] (0x0400): Removing
[0:1:0x0001:1:1:U:ipa.example.com:name=usern...@example.com] from reply
table
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]]
[dp_req_destructor] (0x0400): DP Request [Account #5]: Request removed.
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]]
[dp_req_destructor] (0x0400): Number of active DP request: 0
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]]
[sdap_process_result] (0x2000): Trace: sh[0x7f14ec425550], connected[1],
ops[(nil)], ldap[0x7f14ec409710]
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]]
[sdap_process_result] (0x2000): Trace: end of ldap_result list
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]] [sbus_dispatch]
(0x4000): dbus conn: 0x7f14ec428290
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]] [sbus_dispatch]
(0x4000): Dispatching.
(Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]]

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-10 Thread Michael Gusek via FreeIPA-users 
Hello,

following steps works in my cloned test scenario:

cp
/var/log/pki/server/upgrade/10.2.2/1/oldfiles/var/lib/pki/pki-tomcat/conf/Catalina/localhost/ca.xml
/etc/pki/pki-tomcat/Catalina/localhost/ca.xml
rsync -a
/var/log/pki/server/upgrade/10.2.2/1/oldfiles/var/lib/pki/pki-tomcat/webapps/var/lib/pki/pki-tomcat/webapps/
ipactl start
systemctl restart certmonger

certmonger will renew certificates. In my catalina logfile, i can find
this exception:

Jul 30, 2017 8:00:32 AM org.apache.catalina.core.StandardContext
resourcesStart
SCHWERWIEGEND: Error starting static Resources
java.lang.IllegalArgumentException: Document base
/usr/share/pki/server/common/webapps/pki does not exist or is not a
readable directory
  at
org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:136)
  at
org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:5197)
  at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5386)
  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
  at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899)
  at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
  at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
  at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
  at java.security.AccessController.doPrivileged(Native Method)
  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873)
  at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
  at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:679)
  at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

So i think something went wrong with updating FreeIPA in the past, there
must be a change from webapps/ca to webapps/pki. Which steps did i miss ?

Michael


Am 09.08.2017 um 19:03 schrieb Rob Crittenden:
> Michael Gusek wrote:
>> Hello Rob,
>>
>> i can understand why CA won't start with expired certs. Actually my
>> system date is a day before expiring (expiring date is 30 Jul 2017,
>> system date now 29 Jul 2017), but CA won't start. How to "ensure that
>> the CA comes up" ?
> Ok, well the logs I responded to were from [07/Aug/2017:14:21:41].
>
> ipactl is going to restart ntpd which would revert the time.
>
> What I'd try is:
>
> - ipactl stop
> - service ntpd stop (to be sure)
> - date 
> - service pki-tomcatd@pki-tomcat.service start
>
> To see if the CA came up:
>
> curl http://`hostname`:8080/ca/ee/ca/getCertChain
>
> If so then service certmonger restart
>
> rob
>
>> Michael
>>
>>
>> Am 08.08.2017 um 17:40 schrieb Rob Crittenden:
>>> Michael Gusek via FreeIPA-users wrote:
>>>> Hi Fraser,
>>>>
>>>> at the moment, i can't provide this logfile, i've moved that back to
>>>> have only new log lines. But a new new logfile is not created ??? In my
>>>> old logfile i have some lines after switch to basic auth, but before
>>>> setting time to past:
>>>>
>>> The CA won't start with expired certs.
>>>
>>> I'd set the time back to the past and ensure that the CA comes up. The
>>> debug log in that case should tell you what is going on. Be sure that
>>> ntpd is stopped.
>>>
>>> Restarting certmonger should be sufficient to have it try renewal as it
>>> will see on startup that the certs need to be refreshed.
>>>
>>> rob
>>

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-09 Thread Michael Gusek via FreeIPA-users 
Hello Tomasz,

thx for your hint. I've disabled all selftests in
/etc/pki/pki-tomcat/ca/CS.cfg and /etc/pki/pki-tomcat/kra/CS.cfg. There
where only one test. But i did'nt get any success. CA won't start. :(

Michael


Am 09.08.2017 um 15:24 schrieb Tomasz Torcz via FreeIPA-users:
> On Wed, Aug 09, 2017 at 01:32:43PM +0200, Michael Gusek via FreeIPA-users 
> wrote:
>> Hello Rob,
>>
>> i can understand why CA won't start with expired certs. Actually my
>> system date is a day before expiring (expiring date is 30 Jul 2017,
>> system date now 29 Jul 2017), but CA won't start. How to "ensure that
>> the CA comes up" ?
>   There are couple of certificate selftests run at startup, you can see
> the logs at
>
>   /var/log/pki/pki-tomcat/ca/selftests.log
>
>   If any of them fails, CA won't start. You will have to fix the situation 
> causing
> test to fail or disabled them alltogether (/etc/pki/pki-tomcat/ca/CS.cfg, look
> for selftest.container.*).
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-09 Thread Michael Gusek via FreeIPA-users 
One more info. After starting tomcat-pki i have a exception in
catalina.2017-07-29.log:

Jul 29, 2017 10:06:58 AM org.apache.catalina.core.ContainerBase
addChildInternal
SCHWERWIEGEND: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/pki]]
  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:153)
  at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899)
  at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
  at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
  at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
  at java.security.AccessController.doPrivileged(Native Method)
  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873)
  at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
  at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:679)
  at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.catalina.LifecycleException: Error in resourceStart()
  at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5387)
  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
  ... 14 more

Jul 29, 2017 10:06:58 AM org.apache.catalina.startup.HostConfig
deployDescriptor
SCHWERWIEGEND: Error deploying configuration descriptor
/etc/pki/pki-tomcat/Catalina/localhost/pki.xml
java.lang.IllegalStateException: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/pki]]
  at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:903)
  at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
  at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
  at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
  at java.security.AccessController.doPrivileged(Native Method)
  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873)
  at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
  at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:679)
  at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

I think thats we reason why CA not available, but there is no info whats
the underlying problem is.

Michael


Am 09.08.2017 um 13:32 schrieb Michael Gusek via FreeIPA-users:
>
> Hello Rob,
>
> i can understand why CA won't start with expired certs. Actually my
> system date is a day before expiring (expiring date is 30 Jul 2017,
> system date now 29 Jul 2017), but CA won't start. How to "ensure that
> the CA comes up" ?
>
> Michael
>
>
> Am 08.08.2017 um 17:40 schrieb Rob Crittenden:
>> Michael Gusek via FreeIPA-users wrote:
>>> Hi Fraser,
>>>
>>> at the moment, i can't provide this logfile, i've moved that back to
>>> have only new log lines. But a new new logfile is not created ??? In my
>>> old logfile i have some lines after switch to basic auth, but before
>>> setting time to past:
>>>
>> The CA won't start with expired certs.
>>
>> I'd set the time back to the past and ensure that the CA comes up. The
>> debug log in that case should tell you what is going on. Be sure that
>> ntpd is stopped.
>>
>> Restarting certmonger should be sufficient to have it try renewal as it
>> will see on startup that the certs need to be refreshed.
>>
>> rob
>
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

-- 




*Michael**Gusek*| System Administrator| Webtrekk GmbH |
*t*+49 30 755 415 302| *f *+49 30 755 415 100 | *w *www.webtrekk.com
<https:/

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-09 Thread Michael Gusek via FreeIPA-users 
Hello Rob,

i can understand why CA won't start with expired certs. Actually my
system date is a day before expiring (expiring date is 30 Jul 2017,
system date now 29 Jul 2017), but CA won't start. How to "ensure that
the CA comes up" ?

Michael


Am 08.08.2017 um 17:40 schrieb Rob Crittenden:
> Michael Gusek via FreeIPA-users wrote:
>> Hi Fraser,
>>
>> at the moment, i can't provide this logfile, i've moved that back to
>> have only new log lines. But a new new logfile is not created ??? In my
>> old logfile i have some lines after switch to basic auth, but before
>> setting time to past:
>>
> The CA won't start with expired certs.
>
> I'd set the time back to the past and ensure that the CA comes up. The
> debug log in that case should tell you what is going on. Be sure that
> ntpd is stopped.
>
> Restarting certmonger should be sufficient to have it try renewal as it
> will see on startup that the certs need to be refreshed.
>
> rob


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-08 Thread Michael Gusek via FreeIPA-users 
(StandardWrapper.java:1195)
  at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1085)
  at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5318)
  at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5610)
  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
  at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899)
  at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
  at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
 at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
  at java.security.AccessController.doPrivileged(Native Method)
  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873)
  at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
  at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:679)
  at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
  at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  at java.lang.Thread.run(Thread.java:745)
[07/Aug/2017:14:21:42][localhost-startStop-1]: CMSEngine.shutdown()
...

I snipped some (hopefully unrelevant line's), as you can see simple bind
works and we have an exception because expired certificates.
I stuck in missing debug-file, i don't understand why it is'nt
recreated. From my perspective i think, ca is not starting up so no
debug file.

Michael

Am 08.08.2017 um 14:15 schrieb Fraser Tweedale:
> On Tue, Aug 08, 2017 at 01:52:40PM +0200, Michael Gusek via FreeIPA-users 
> wrote:
>> Hello,
>>
>> we run in a problem with expired certificates:
>>
>>> getcert list (sample show only one expired certificate)
>> ...
>> Request ID '20170202144747':
>>   status: MONITORING
>>   stuck: no
>>   key pair storage:
>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>>   certificate:
>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
>> Certificate DB'
>>   CA: dogtag-ipa-ca-renew-agent
>>   issuer: CN=Certificate Authority,O=NBG.WEBTREKK.COM
>>   subject: CN=IPA RA,O=NBG.WEBTREKK.COM
>>   expires: 2017-07-30 13:37:02 UTC
>>   key usage:
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>   eku: id-kp-serverAuth,id-kp-clientAuth
>>   pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
>>   post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
>>   track: yes
>>   auto-renew: yes
>>
>> ...
>> Request ID '20170202144746':
>>   status: MONITORING
>>   stuck: no
>>   key pair storage:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
>> cert-pki-ca',token='NSS Certificate DB',pin set
>>   certificate:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
>> cert-pki-ca',token='NSS Certificate DB'
>>   CA: dogtag-ipa-ca-renew-agent
>>   issuer: CN=Certificate Authority,O=NBG.WEBTREKK.COM
>>   subject: CN=Certificate Authority,O=NBG.WEBTREKK.COM
>>   expires: 2035-08-10 13:36:23 UTC
>>   key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
>>   pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>>   post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> "caSigningCert cert-pki-ca"
>>   track: yes
>>   auto-renew: yes
>> ...
>>
>> We follow instruction to renew certificates found on this mailing list:
>> * set system time before expired
>> * set dogtag to use simple binds instead of TLS to connect to LDAP
>> * ipactl start --ignore-service-failures
>> * systemctl restart pki-tomcatd@pki-tomcat
>> * systemctl restart certmonger
>> * resubmit one of expired certificate: ipa-getcert resubmit -i
>> 20170202144747
>>
>> Jul 29 13:27:05 ipa-prod-01.
>> dogtag-ipa-ca-renew-agent-submit[10651]: Forwarding request to
>> dogtag-ipa-renew-agent  
>> Jul 29 13:27:05 ipa-prod-01.
>> dogtag-ipa-renew-agent-submit[10661]: GET http://ipa-prod-01.:8080/
>> ca/ee/ca/profileSubmit?profileId=caServerCert_num=7=true=true
>>   
>>  
>> Jul 29 13:27:05 ipa-prod-01.
>> dogtag-ipa-renew-agent-submit[10661]: Apache
>> Tomcat/7.0.69

[Freeipa-users] expired certificates - pki-tomcat not running

2017-08-08 Thread Michael Gusek via FreeIPA-users 
Hello,

we run in a problem with expired certificates:

> getcert list (sample show only one expired certificate)
...
Request ID '20170202144747':
  status: MONITORING
  stuck: no
  key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
  certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB'
  CA: dogtag-ipa-ca-renew-agent
  issuer: CN=Certificate Authority,O=NBG.WEBTREKK.COM
  subject: CN=IPA RA,O=NBG.WEBTREKK.COM
  expires: 2017-07-30 13:37:02 UTC
  key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
  eku: id-kp-serverAuth,id-kp-clientAuth
  pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
  post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
  track: yes
  auto-renew: yes

...
Request ID '20170202144746':
  status: MONITORING
  stuck: no
  key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
  certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB'
  CA: dogtag-ipa-ca-renew-agent
  issuer: CN=Certificate Authority,O=NBG.WEBTREKK.COM
  subject: CN=Certificate Authority,O=NBG.WEBTREKK.COM
  expires: 2035-08-10 13:36:23 UTC
  key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
  pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
  post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"caSigningCert cert-pki-ca"
  track: yes
  auto-renew: yes
...

We follow instruction to renew certificates found on this mailing list:
* set system time before expired
* set dogtag to use simple binds instead of TLS to connect to LDAP
* ipactl start --ignore-service-failures
* systemctl restart pki-tomcatd@pki-tomcat
* systemctl restart certmonger
* resubmit one of expired certificate: ipa-getcert resubmit -i
20170202144747

Jul 29 13:27:05 ipa-prod-01.
dogtag-ipa-ca-renew-agent-submit[10651]: Forwarding request to
dogtag-ipa-renew-agent  
Jul 29 13:27:05 ipa-prod-01.
dogtag-ipa-renew-agent-submit[10661]: GET http://ipa-prod-01.:8080/
ca/ee/ca/profileSubmit?profileId=caServerCert_num=7=true=true
  
 
Jul 29 13:27:05 ipa-prod-01.
dogtag-ipa-renew-agent-submit[10661]: Apache
Tomcat/7.0.69 -
or report HTTP Status 404 - /ca/ee/ca/profileSubmittype Status reportmessage
 /ca/ee/ca/profileSubmitdescription The
requested resource is not available.Apache
Tomcat/7.0.69

 
Jul 29 13:27:05 ipa-prod-01.
dogtag-ipa-ca-renew-agent-submit[10651]: dogtag-ipa-renew-agent returned 2  


In certmonger logs, we can see that the request is forwarded to
dogtag-ipa-renew-agent, but agent returned with return code 2, which
seemed to be "request rejected". So at this point I have no glue to
solve this problem. Any help is desired.

> ipa
--version   
  
 
VERSION: 4.4.0, API_VERSION: 2.213  

Many thanks

Michael
-- 




*Michael**Gusek*| System Administrator| Webtrekk GmbH |
*t*+49 30 755 415 302| *f *+49 30 755 415 100 | *w *www.webtrekk.com

Amtsgericht/Local Court Berlin, HRB 93435 B | Geschäftsführer/CEO
Christian Sauer


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org