[Freeipa-users] Re: Freeipa Certficates issues

[Julien Honore via FreeIPA-users]

Hi, 

Do you think if i upgrade the version of my ipa server, it will be better ?

I am at the version 3.0. 

Thank you for your time.



Julien Honore

- Original Message -
From: "Julien Honore" 
To: "freeipa-users" 
Cc: "Florence Blanc-Renaud" 
Sent: Wednesday, 30 August, 2017 10:44:38
Subject: Re: [Freeipa-users] Freeipa Certficates issues

Hi Flo,

When I try to apply the command. the result is: 

ipa-getkeytab --principal=host/$vltws01.vit@vit.lan
Usage: ipa-getkeytab [-qPr?] [-q|--quiet] [-s|--server=Server Name]
[-p|--principal=Kerberos Service Principal Name]
[-k|--keytab=Keytab File Name]
[-e|--enctypes=Comma separated encryption types list]
[--permitted-enctypes] [-P|--password]
[-D|--binddn=DN to bind as if not using kerberos]
[-w|--bindpw=password to use if not using kerberos] [-r|--retrieve]
[-?|--help] [--usage]

I tried with a different way 

ipa-getkeytab -p host/vltws01.vit.lan
Usage: ipa-getkeytab [-qPr?] [-q|--quiet] [-s|--server=Server Name]
[-p|--principal=Kerberos Service Principal Name]
[-k|--keytab=Keytab File Name]
[-e|--enctypes=Comma separated encryption types list]
[--permitted-enctypes] [-P|--password]
[-D|--binddn=DN to bind as if not using kerberos]
[-w|--bindpw=password to use if not using kerberos] [-r|--retrieve]
[-?|--help] [--usage]

And when I tried with the ipa-server, I have this result: 

ipa-getkeytab -s auth0.vit.lan -p host/vltws01.vit.lan -k /etc/krb5.keytab
Kerberos User Principal not found. Do you have a valid Credential Cache?

Like I said at the beginning, I changed the date on the IPA-Server and the 
users can continue to work. 

I don't understant why the certificates did not auto renew after they were 
expired. 

Thank you. 

Julien Honore

- Original Message -
From: "Florence Blanc-Renaud" 
To: "Julien Honore" , "freeipa-users" 

Sent: Wednesday, 30 August, 2017 09:11:00
Subject: Re: [Freeipa-users] Freeipa Certficates issues

On 08/29/2017 06:43 PM, Julien Honore wrote:
> Hi Florence,
> 
> Thank you for the reply.
> 
> When I execute the command sudo kinit -kt /etc/krb5.keytab
> the result is :
> kinit: Clients credentials have been revoked while getting initial credentials
> 
> When I try the command ipa-getkeytab, I don't have the same option.
> 
Hi,

(putting mailing list back in the recipients list)
you are right, the --retrieve option was added only in IPA 4.x.

If you run ipa-getkeytab without the -r option, it will request a new 
host keytab (all other keytabs previously obtained will be invalidated). 
So this should unblock certmonger, but if you were using the host keytab 
in other places you will need to overwrite them with the new keytab.

Flo

> Thank you.
> 
> Julien Honore.
> 
> - Original Message -
> From: "Florence Blanc-Renaud" 
> To: "freeipa-users" 
> Cc: "Julien Honore" 
> Sent: Tuesday, 29 August, 2017 12:14:10
> Subject: Re: [Freeipa-users] Freeipa Certficates issues
> 
> On 08/29/2017 04:09 PM, Julien Honore via FreeIPA-users wrote:
>>
>> Hi,
>>
>> I have an issue with my freeipa server.
>>
>> The certificates expired and I can't resubmit.
>>
>> I put the date before the expiration of the certs.
>>
>> The result of ipa-getcert list :
>>
>>
>> Number of certificates and requests being tracked: 8.
>> Request ID '20150805183502':
>> status: MONITORING
>> ca-error: Error setting up ccache for "host" service on client using
>> default keytab: Clients credentials have been revoked.
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/etc/dirsrv/slapd-VIT-LAN',nickname='Server-Cert',token='NSS
>> Certificate DB',pinfile='/etc/dirsrv/slapd-VIT-LAN/pwdfile.txt'
>> certificate:
>> type=NSSDB,location='/etc/dirsrv/slapd-VIT-LAN',nickname='Server-Cert',token='NSS
>> Certificate DB'
>> CA: IPA
>> issuer: CN=Certificate Authority,O=VIT.LAN
>> subject: CN=auth0.vit.lan,O=VIT.LAN
>> expires:2017-08-05 18 :35:02 UTC
>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>> eku: id-kp-serverAuth,id-kp-clientAuth
>> pre-save command:
>> post-save command:
>> track: yes
>> auto-renew: yes
>> Request ID '20150805183539':
>> status: MONITORING
>> ca-error: Error setting up ccache for "host" service on client using
>> default keytab: Clients credentials have been revoked.
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
>> Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt'
>> certificate:
>> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
>> Certificate DB'
>> CA: IPA
>> issuer: CN=Certificate Authority,O=VIT.LAN
>> subject: CN=auth0.vit.lan,O=VIT.LAN
>> 

[Freeipa-users] Re: sudo policy doesn't work since host is installed with CNAME

[Z D via FreeIPA-users]

This is resolved by updating sudo package.


---> Package sudo.x86_64 0:1.8.6p7-11.el7 will be updated
---> Package sudo.x86_64 0:1.8.19p2-10.el7 will be an update



From: Pavel Březina 
Sent: Thursday, August 31, 2017 1:48:33 AM
To: Jakub Hrozek; Z D
Cc: FreeIPA users list
Subject: Re: [Freeipa-users] Re: sudo policy doesn't work since host is 
installed with CNAME

On 08/31/2017 08:35 AM, Jakub Hrozek wrote:
> On Wed, Aug 30, 2017 at 08:51:24PM +, Z D wrote:
>>> Does ipa_hostname in sssd.conf point to cname (or, the hostname registered 
>>> with IPA) ?
>>
>>
>> It points to the DNS A record, the one that is registered with IPA.
>
> Pavel, is a setup with a machne where the hostname in IPA doesn't match
> the machine hostname known to work?

sudo should read ipa_hostname from /etc/sssd/sssd.conf so if this option
is present, it should work. If it does not, we need sudo debug logs.

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

[Freeipa-users] Unable to create an Active Directory Trust

[PAESSENS Daniel (BCS/PSD) via FreeIPA-users]

Hello,

When performing a trust between IPA & AD I get the following error:

CIFS server communication error: code "-1073741771", message "The object name 
already exists." (both may be "None")

For testing purpose did I remove the trust and want to re-add him like before.

Regards,

Daniel



 DISCLAIMER
http://www.bics.com/maildisclaimer/
___
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

[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 time or does it keep trying the bad one even if it should be trying
> the one that is up?
>
> By the way, I'm suprised that the failover doesn't work for you. This is a
> quite basic feature that had been developed years ago. Can you also specify
> exactly how you bring one of the IDM servers down? Do you power it off,
> run ipactl stop, ...?
>
>> |(Wed Aug 23 16:10:14 2017) [[sssd[ldap_child[2129
>>