[Freeipa-users] ipa: ERROR: did not receive Kerberos credentials
Hello all When I try to execute and commands from the an ipa-replica I get [rkelly@replicahostname ~]$ ipa user-find ipa: ERROR: did not receive Kerberos credentials [rkelly@replicahostname ~]$ kinit Password for rke...@ipa2.dc.sita.aero: [rkelly@replicahostname ~]$ ipa user-find ipa: ERROR: did not receive Kerberos credentials [rkelly@replicahostname ~]$ klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_159910_qojy7v) I thought perhaps the two are out of sync [root@replicahostname ~]# ipa-replica-manage re-initialize --from liipaxs010p.ipa2.dc.sita.aero Invalid password ipa-replica-conncheck says communication is ok. I looked at the httpd, secure,and krb log and none show any activity when I execute the commands above. Im lost any clues as to where I can look for answers? Thank You, Rashard Kelly This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click here to register http://www.sitasummit.aero ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] DDNS with DHCPD and IPA
On 04/10/2014 06:50 AM, Arthur Fayzullin wrote: If this http://www.freeipa.org/page/Howto/ISC_DHCPd_and_Dynamic_DNS_update is it, then it is quite not easy to understand what is it about. here, in mail-list it was much more understandable. The HOWTOs provided in http://www.freeipa.org/page/HowTos are mostly FreeIPA community provided pages. FreeIPA developers cannot have direct experience with integration with all 3rd party projects which is why we welcome help from community with documenting the integration procedures. If you think the HOWTO is not clear enough, please feel free update it and make it more clear and thus help others too. 10.04.2014 00:20, Dmitri Pal ?: On 04/09/2014 11:58 AM, Andy Tomlin wrote: Ok, I added a howto page Thanks Martin, should be link it from HowTo page? It was linked. I just updated the page and added better formatting and interlinks. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials
On 04/10/2014 08:31 AM, rashard.ke...@sita.aero wrote: Hello all When I try to execute and commands from the an ipa-replica I get [rkelly@replicahostname ~]$ ipa user-find ipa: ERROR: did not receive Kerberos credentials [rkelly@replicahostname ~]$ kinit Password for rke...@ipa2.dc.sita.aero: ... [rkelly@replicahostname ~]$ klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_159910_qojy7v) What are the file permissions on /tmp/krb5cc_159910_qojy7v ? I assume that it was made readable to everyone which made Kerberos libraries refused using the CCACHE. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials
On Thu, 10 Apr 2014, rashard.ke...@sita.aero wrote: Hello all When I try to execute and commands from the an ipa-replica I get [rkelly@replicahostname ~]$ ipa user-find ipa: ERROR: did not receive Kerberos credentials [rkelly@replicahostname ~]$ kinit Password for rke...@ipa2.dc.sita.aero: [rkelly@replicahostname ~]$ ipa user-find ipa: ERROR: did not receive Kerberos credentials [rkelly@replicahostname ~]$ klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_159910_qojy7v) I thought perhaps the two are out of sync [root@replicahostname ~]# ipa-replica-manage re-initialize --from liipaxs010p.ipa2.dc.sita.aero Invalid password ipa-replica-conncheck says communication is ok. I looked at the httpd, secure,and krb log and none show any activity when I execute the commands above. Im lost any clues as to where I can look for answers? Let's put IPA commands aside and first find out what's wrong with your Kerberos infra. Looking at your ticket cache file name (FILE:/tmp/krb5cc_159910_qojy7v) I assume you have come to this machine via SSH and the ticket cache is created by the sshd or sssd. The message you received out of klist is shown if ccache file is either: - unaccessible for the user - is a directory rather than a file - is a broken symlink - blocked by some app with explusive locks - cannot be open for a write Please provide output of $ cat /proc/mounts | grep /tmp $ echo $KRB5CCNAME $ ls -lZ /tmp/krb5cc_159910_qojy7v $ KRB5_TRACE=/dev/stderr kinit $ KRB5_TRACE=/dev/stderr klist You can temporarily overcome this issue by selecting a different ticket cache by setting KRB5CCNAME environmental variable: $ export KRB5CCNAME=$HOME/.krb5cc $ kinit $ ipa user-find ... However, it would be good to solve the issue to avoid repeating these problems -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] LDAP Authentication with expired passwords
We have a few services using IPA via LDAP. E.G. Apache connecting to ldap://snip/cn=users,cn=accounts,dc=ipa,dc=snip?uid This works fine but users with expired passwords are still able to authenticate. Is there any way to stop this in FreeIPA, or do I have to check krbPasswordExpiration in my user filter? Thanks Matt ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials
The krb5 files are not readable by everyone. There are multiple krb5 files in tmp, should they automatically be readable by all? BTW our users do not have home directories if that makes a difference. [rkelly@replicahostname ~]$ ls -lZ /tmp |grep krb -rw--- rootroot?krb5cc_0 -rw--- xs05144 xs05144 ? krb5cc_159920_u5RRhd -rw--- rkelly rkelly ? krb5cc_159910_oKtZFE -rw--- rkelly rkelly ? krb5cc_159910_ZekyY0 -rw--- apache apache ?krb5cc_48 ipa-server-selinux-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 ipa-server-3.0.0-37.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 ipa-python-3.0.0-37.el6.x86_64 ipa-admintools-3.0.0-37.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch [rkelly@replicahostname ~]$ cat /proc/mounts | grep /tmp /dev/mapper/system-tmp_vol /tmp ext4 rw,relatime,barrier=1,data=ordered 0 0 [rkelly@replicahostname ~]$ echo $KRB5CCNAME FILE:/tmp/krb5cc_159910_oKtZFE [rkelly@replicahostname ~]$ ls -lZ /tmp/krb5cc_159910_oKtZFE -rw--- rkelly rkelly ? /tmp/krb5cc_159910_oKtZFE [rkelly@replicahostname ~]$ KRB5_TRACE=/dev/stderr kinit [14559] 1397132474.221287: Getting initial credentials for rkelly@DOMAIN [14559] 1397132474.221510: Sending request (191 bytes) to DOMAIN [14559] 1397132474.221677: Sending initial UDP request to dgram 10.228.20.25:88 [14559] 1397132474.225248: Received answer from dgram 10.228.20.25:88 [14559] 1397132474.225287: Response was from master KDC [14559] 1397132474.225306: Received error from KDC: -1765328359/Additional pre-authentication required [14559] 1397132474.225331: Processing preauth types: 136, 19, 2, 133 [14559] 1397132474.225343: Selected etype info: etype aes256-cts, salt IPA2.DC.SITA.AEROrkelly, params [14559] 1397132474.225346: Received cookie: MIT Password for rkelly@DOMAIN: [14559] 1397132484.255381: AS key obtained for encrypted timestamp: aes256-cts/DBF7 [14559] 1397132484.255432: Encrypted timestamp (for 1397132484.255390): plain 301AA011180F32303134303431303132323132345AA105020303E59E, encrypted 321A6A1E297880D1E2D1BF069D6D44136D7A2A0D3AAFC3209CB9B4E5BAAE59E928559E47FD0A140F68D377A8398D7CAB4B735D0612247A7C [14559] 1397132484.255453: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success [14559] 1397132484.255457: Produced preauth for next request: 133, 2 [14559] 1397132484.255474: Sending request (286 bytes) to DOMAIN (master) [14559] 1397132484.255560: Sending initial UDP request to dgram 10.228.20.25:88 [14559] 1397132484.262563: Received answer from dgram 10.228.20.25:88 [14559] 1397132484.262593: Processing preauth types: 19 [14559] 1397132484.262600: Selected etype info: etype aes256-cts, salt DOMAINrkelly, params [14559] 1397132484.262603: Produced preauth for next request: (empty) [14559] 1397132484.262609: AS key determined by preauth: aes256-cts/DBF7 [14559] 1397132484.262650: Decrypted AS reply; session key is: aes256-cts/B097 [14559] 1397132484.262664: FAST negotiation: available [14559] 1397132484.262681: Initializing FILE:/tmp/krb5cc_159910_oKtZFE with default princ rkelly@DOMAIN [rkelly@replicahostname ~]$ KRB5_TRACE=/dev/stderr klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_159910_oKtZFE) -- Thank You, Rashard Kelly From: Alexander Bokovoy aboko...@redhat.com To: rashard.ke...@sita.aero Cc: freeipa-users@redhat.com Date: 04/10/2014 03:25 AM Subject:Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials On Thu, 10 Apr 2014, rashard.ke...@sita.aero wrote: Hello all When I try to execute and commands from the an ipa-replica I get [rkelly@replicahostname ~]$ ipa user-find ipa: ERROR: did not receive Kerberos credentials [rkelly@replicahostname ~]$ kinit Password for rke...@ipa2.dc.sita.aero: [rkelly@replicahostname ~]$ ipa user-find ipa: ERROR: did not receive Kerberos credentials [rkelly@replicahostname ~]$ klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_159910_qojy7v) I thought perhaps the two are out of sync [root@replicahostname ~]# ipa-replica-manage re-initialize --from liipaxs010p.ipa2.dc.sita.aero Invalid password ipa-replica-conncheck says communication is ok. I looked at the httpd, secure,and krb log and none show any activity when I execute the commands above. Im lost any clues as to where I can look for answers? Let's put IPA commands aside and first find out what's wrong with your Kerberos infra. Looking at your ticket cache file name (FILE:/tmp/krb5cc_159910_qojy7v) I assume you have come to this machine via SSH and the ticket cache is created by the sshd or sssd. The message you received out of klist is shown if ccache file is either: - unaccessible
Re: [Freeipa-users] IPA client installation for Solaris 11.
Thanks Rob, those bug reports help.
One more question, in the official Solaris 10 documentation, i see this
stuff -
-a proxyPassword={NS1}*fbc123a92116812*
userPassword:: *e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*=
Is there a way to generate that password hash for a new password. I think
that should be part of the documentation, dont want all Solaris IPA users
to be using the same password and corresponding hash.
Thanks.
On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden rcrit...@redhat.com wrote:
quest monger wrote:
I have read through the official documentation here for Solaris-10 -
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_
Guide/Configuring_an_IPA_Client_on_Solaris.html
I have found a few web posts on how to make it work for Solaris-11.
Have any of you tried adding a Solaris-11 host to an existing IPA
server? If so, do you have any documentation/how-tos/instructions that i
could use to do the same. Any help is appreciated.
I am trying to do this to so I can centralize SSH authentication for all
my Solaris-11 and Linux hosts.
That is pretty much all we've got. There is a bug open with some
documentation updates, https://bugzilla.redhat.com/show_bug.cgi?id=815533and
some more in
https://bugzilla.redhat.com/show_bug.cgi?id=801883
We use sssd to help with centralized SSH auth so it probably won't work as
smoothly on Solaris as it does on sssd-based Linux systems. See
sss_ssh_authorizedkeys(1) and sss_ssh_knownhostsproxy(8).
This document describes how it works in IPA
http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials
I can run commands after changing the permissions on the files, but why is it generating files that are not world readable? [rkelly@replicahostname ~]$ ll total 84 -rw-r--r-- 1 rootroot 2428 Apr 9 22:34 krb5cc_0 -rw-r--r-- 1 xs05144 xs05144 1146 Apr 3 16:10 krb5cc_159920_u5RRhd -rw-r--r-- 1 rkelly rkelly569 Apr 10 15:14 krb5cc_159910_CUkupo -rw-r--r-- 1 rkelly rkelly 1873 Apr 9 23:40 krb5cc_159910_ZekyY0 -rw-r--r-- 1 apache apache662 Apr 10 06:02 krb5cc_48 [rkelly@replicahostname ~]$ klist Ticket cache: FILE:/tmp/krb5cc_159910_CUkupo Default principal: rkelly@DOMAIN Valid starting ExpiresService principal 04/10/14 15:14:40 04/11/14 15:14:40 krbtgt/IPA2.DC.SITA.AERO@DOMAIN [rkelly@replicahostname ~]$ ipa user-find kelly -- 1 user matched -- User login: rkelly First name: Rashard Last name: KElly Home directory: /home/rkelly Login shell: /bin/sh Email address: rkelly@domain UID: 159910 GID: 159910 Account disabled: False Password: True Kerberos keys available: True Number of entries returned 1 Thank You, Rashard Kelly From: rashard.ke...@sita.aero To: Alexander Bokovoy aboko...@redhat.com Cc: freeipa-users@redhat.com Date: 04/10/2014 08:42 AM Subject:Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials Sent by:freeipa-users-boun...@redhat.com The krb5 files are not readable by everyone. There are multiple krb5 files in tmp, should they automatically be readable by all? BTW our users do not have home directories if that makes a difference. [rkelly@replicahostname ~]$ ls -lZ /tmp |grep krb -rw--- rootroot?krb5cc_0 -rw--- xs05144 xs05144 ? krb5cc_159920_u5RRhd -rw--- rkelly rkelly ? krb5cc_159910_oKtZFE -rw--- rkelly rkelly ? krb5cc_159910_ZekyY0 -rw--- apache apache ?krb5cc_48 ipa-server-selinux-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 ipa-server-3.0.0-37.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 ipa-python-3.0.0-37.el6.x86_64 ipa-admintools-3.0.0-37.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch [rkelly@replicahostname ~]$ cat /proc/mounts | grep /tmp /dev/mapper/system-tmp_vol /tmp ext4 rw,relatime,barrier=1,data=ordered 0 0 [rkelly@replicahostname ~]$ echo $KRB5CCNAME FILE:/tmp/krb5cc_159910_oKtZFE [rkelly@replicahostname ~]$ ls -lZ /tmp/krb5cc_159910_oKtZFE -rw--- rkelly rkelly ? /tmp/krb5cc_159910_oKtZFE [rkelly@replicahostname ~]$ KRB5_TRACE=/dev/stderr kinit [14559] 1397132474.221287: Getting initial credentials for rkelly@DOMAIN [14559] 1397132474.221510: Sending request (191 bytes) to DOMAIN [14559] 1397132474.221677: Sending initial UDP request to dgram 10.228.20.25:88 [14559] 1397132474.225248: Received answer from dgram 10.228.20.25:88 [14559] 1397132474.225287: Response was from master KDC [14559] 1397132474.225306: Received error from KDC: -1765328359/Additional pre-authentication required [14559] 1397132474.225331: Processing preauth types: 136, 19, 2, 133 [14559] 1397132474.225343: Selected etype info: etype aes256-cts, salt IPA2.DC.SITA.AEROrkelly, params [14559] 1397132474.225346: Received cookie: MIT Password for rkelly@DOMAIN: [14559] 1397132484.255381: AS key obtained for encrypted timestamp: aes256-cts/DBF7 [14559] 1397132484.255432: Encrypted timestamp (for 1397132484.255390): plain 301AA011180F32303134303431303132323132345AA105020303E59E, encrypted 321A6A1E297880D1E2D1BF069D6D44136D7A2A0D3AAFC3209CB9B4E5BAAE59E928559E47FD0A140F68D377A8398D7CAB4B735D0612247A7C [14559] 1397132484.255453: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success [14559] 1397132484.255457: Produced preauth for next request: 133, 2 [14559] 1397132484.255474: Sending request (286 bytes) to DOMAIN (master) [14559] 1397132484.255560: Sending initial UDP request to dgram 10.228.20.25:88 [14559] 1397132484.262563: Received answer from dgram 10.228.20.25:88 [14559] 1397132484.262593: Processing preauth types: 19 [14559] 1397132484.262600: Selected etype info: etype aes256-cts, salt DOMAINrkelly, params [14559] 1397132484.262603: Produced preauth for next request: (empty) [14559] 1397132484.262609: AS key determined by preauth: aes256-cts/DBF7 [14559] 1397132484.262650: Decrypted AS reply; session key is: aes256-cts/B097 [14559] 1397132484.262664: FAST negotiation: available [14559] 1397132484.262681: Initializing FILE:/tmp/krb5cc_159910_oKtZFE with default princ rkelly@DOMAIN [rkelly@replicahostname ~]$ KRB5_TRACE=/dev/stderr klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache
Re: [Freeipa-users] LDAP Authentication with expired passwords
On 04/10/2014 08:03 AM, Matthew Symonds wrote: We have a few services using IPA via LDAP. E.G. Apache connecting to ldap://snip/cn=users,cn=accounts,dc=ipa,dc=snip?uid This works fine but users with expired passwords are still able to authenticate. Is there any way to stop this in FreeIPA, or do I have to check krbPasswordExpiration in my user filter? There is no way to stop it. You can read about the reasons in the ticket and mentioned threads. https://fedorahosted.org/freeipa/ticket/1539#comment:13 Using it in the access control filter would be a reasonable workaround. Thanks Matt ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA client installation for Solaris 11.
On 04/10/2014 11:41 AM, quest monger wrote:
Thanks Rob, those bug reports help.
One more question, in the official Solaris 10 documentation, i see
this stuff -
-aproxyPassword={NS1}*fbc123a92116812*
userPassword::*e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*=
Is there a way to generate that password hash for a new password. I
think that should be part of the documentation, dont want all Solaris
IPA users to be using the same password and corresponding hash.
Can you rephrase the question?
It is unclear what hash you are asking about.
If you are using IPA you do not need local password hashes.
Thanks.
On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden rcrit...@redhat.com
mailto:rcrit...@redhat.com wrote:
quest monger wrote:
I have read through the official documentation here for
Solaris-10 -
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html
I have found a few web posts on how to make it work for
Solaris-11.
Have any of you tried adding a Solaris-11 host to an existing IPA
server? If so, do you have any
documentation/how-tos/instructions that i
could use to do the same. Any help is appreciated.
I am trying to do this to so I can centralize SSH
authentication for all
my Solaris-11 and Linux hosts.
That is pretty much all we've got. There is a bug open with some
documentation updates,
https://bugzilla.redhat.com/show_bug.cgi?id=815533 and some more
in https://bugzilla.redhat.com/show_bug.cgi?id=801883
We use sssd to help with centralized SSH auth so it probably won't
work as smoothly on Solaris as it does on sssd-based Linux
systems. See sss_ssh_authorizedkeys(1) and sss_ssh_knownhostsproxy(8).
This document describes how it works in IPA
http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials
On Thu, Apr 10, 2014 at 11:55:05AM -0400, rashard.ke...@sita.aero wrote: I can run commands after changing the permissions on the files, but why is it generating files that are not world readable? [rkelly@replicahostname ~]$ ll total 84 -rw-r--r-- 1 rootroot 2428 Apr 9 22:34 krb5cc_0 -rw-r--r-- 1 xs05144 xs05144 1146 Apr 3 16:10 krb5cc_159920_u5RRhd -rw-r--r-- 1 rkelly rkelly569 Apr 10 15:14 krb5cc_159910_CUkupo -rw-r--r-- 1 rkelly rkelly 1873 Apr 9 23:40 krb5cc_159910_ZekyY0 -rw-r--r-- 1 apache apache662 Apr 10 06:02 krb5cc_48 Please don't do this, the credential cache files are similar to your password, only the user itself should be allowed to read it. When you use ls with the -Z option there is a '?' where the SELinux context should be printed. Maybe there are issues with your SELinux setup which prevent access to the ccache files? Can you try SELinux in permissive mode? If there are still issues running klist which strace might give some more details why the ccache file cannot be read. HTH bye, Sumit [rkelly@replicahostname ~]$ klist Ticket cache: FILE:/tmp/krb5cc_159910_CUkupo Default principal: rkelly@DOMAIN Valid starting ExpiresService principal 04/10/14 15:14:40 04/11/14 15:14:40 krbtgt/IPA2.DC.SITA.AERO@DOMAIN [rkelly@replicahostname ~]$ ipa user-find kelly -- 1 user matched -- User login: rkelly First name: Rashard Last name: KElly Home directory: /home/rkelly Login shell: /bin/sh Email address: rkelly@domain UID: 159910 GID: 159910 Account disabled: False Password: True Kerberos keys available: True Number of entries returned 1 Thank You, Rashard Kelly From: rashard.ke...@sita.aero To: Alexander Bokovoy aboko...@redhat.com Cc: freeipa-users@redhat.com Date: 04/10/2014 08:42 AM Subject:Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials Sent by:freeipa-users-boun...@redhat.com The krb5 files are not readable by everyone. There are multiple krb5 files in tmp, should they automatically be readable by all? BTW our users do not have home directories if that makes a difference. [rkelly@replicahostname ~]$ ls -lZ /tmp |grep krb -rw--- rootroot?krb5cc_0 -rw--- xs05144 xs05144 ? krb5cc_159920_u5RRhd -rw--- rkelly rkelly ? krb5cc_159910_oKtZFE -rw--- rkelly rkelly ? krb5cc_159910_ZekyY0 -rw--- apache apache ?krb5cc_48 ipa-server-selinux-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 ipa-server-3.0.0-37.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 ipa-python-3.0.0-37.el6.x86_64 ipa-admintools-3.0.0-37.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch [rkelly@replicahostname ~]$ cat /proc/mounts | grep /tmp /dev/mapper/system-tmp_vol /tmp ext4 rw,relatime,barrier=1,data=ordered 0 0 [rkelly@replicahostname ~]$ echo $KRB5CCNAME FILE:/tmp/krb5cc_159910_oKtZFE [rkelly@replicahostname ~]$ ls -lZ /tmp/krb5cc_159910_oKtZFE -rw--- rkelly rkelly ? /tmp/krb5cc_159910_oKtZFE [rkelly@replicahostname ~]$ KRB5_TRACE=/dev/stderr kinit [14559] 1397132474.221287: Getting initial credentials for rkelly@DOMAIN [14559] 1397132474.221510: Sending request (191 bytes) to DOMAIN [14559] 1397132474.221677: Sending initial UDP request to dgram 10.228.20.25:88 [14559] 1397132474.225248: Received answer from dgram 10.228.20.25:88 [14559] 1397132474.225287: Response was from master KDC [14559] 1397132474.225306: Received error from KDC: -1765328359/Additional pre-authentication required [14559] 1397132474.225331: Processing preauth types: 136, 19, 2, 133 [14559] 1397132474.225343: Selected etype info: etype aes256-cts, salt IPA2.DC.SITA.AEROrkelly, params [14559] 1397132474.225346: Received cookie: MIT Password for rkelly@DOMAIN: [14559] 1397132484.255381: AS key obtained for encrypted timestamp: aes256-cts/DBF7 [14559] 1397132484.255432: Encrypted timestamp (for 1397132484.255390): plain 301AA011180F32303134303431303132323132345AA105020303E59E, encrypted 321A6A1E297880D1E2D1BF069D6D44136D7A2A0D3AAFC3209CB9B4E5BAAE59E928559E47FD0A140F68D377A8398D7CAB4B735D0612247A7C [14559] 1397132484.255453: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success [14559] 1397132484.255457: Produced preauth for next request: 133, 2 [14559] 1397132484.255474: Sending request (286 bytes) to DOMAIN (master) [14559] 1397132484.255560: Sending initial UDP request to dgram 10.228.20.25:88 [14559] 1397132484.262563: Received answer from dgram 10.228.20.25:88 [14559] 1397132484.262593:
Re: [Freeipa-users] IPA client installation for Solaris 11.
Sorry about that. So I am Looking at the Solaris 10 client documentation
here -
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html
It says do the following on Solaris client -
ldapclient manual
...
-a proxyPassword={NS1}fbc123a92116812
...
Whats that proxyPassword for?
Thanks.
On Thu, Apr 10, 2014 at 12:09 PM, Dmitri Pal d...@redhat.com wrote:
On 04/10/2014 11:41 AM, quest monger wrote:
Thanks Rob, those bug reports help.
One more question, in the official Solaris 10 documentation, i see this
stuff -
-a proxyPassword={NS1}*fbc123a92116812*
userPassword::
*e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*=
Is there a way to generate that password hash for a new password. I
think that should be part of the documentation, dont want all Solaris IPA
users to be using the same password and corresponding hash.
Can you rephrase the question?
It is unclear what hash you are asking about.
If you are using IPA you do not need local password hashes.
Thanks.
On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden rcrit...@redhat.comwrote:
quest monger wrote:
I have read through the official documentation here for Solaris-10 -
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html
I have found a few web posts on how to make it work for Solaris-11.
Have any of you tried adding a Solaris-11 host to an existing IPA
server? If so, do you have any documentation/how-tos/instructions that i
could use to do the same. Any help is appreciated.
I am trying to do this to so I can centralize SSH authentication for all
my Solaris-11 and Linux hosts.
That is pretty much all we've got. There is a bug open with some
documentation updates, https://bugzilla.redhat.com/show_bug.cgi?id=815533and
some more in
https://bugzilla.redhat.com/show_bug.cgi?id=801883
We use sssd to help with centralized SSH auth so it probably won't work
as smoothly on Solaris as it does on sssd-based Linux systems. See
sss_ssh_authorizedkeys(1) and sss_ssh_knownhostsproxy(8).
This document describes how it works in IPA
http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf
rob
___
Freeipa-users mailing
listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Using puppet to add servers to IPA
Hello, I'm looking to use puppet to add my servers to IPA automatically. This would be used when building VMs from templates and their first puppet run would add them into IPA. I am wondering if anyone has any success with doing this? Any thing I should consider... any gotchas. Thanks! -- Brent S. Clark NOC Engineer 2580 55th St. | Boulder, Colorado 80301 www.tendrilinc.com | blog http://www.tendrilinc.com/news-room/blog/ http://www.tendrilinc.com/ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using puppet to add servers to IPA
On 04/10/2014 12:24 PM, Brent Clark wrote: Hello, I'm looking to use puppet to add my servers to IPA automatically. This would be used when building VMs from templates and their first puppet run would add them into IPA. Google returns this http://forge.puppetlabs.com/tags/freeipa https://github.com/purpleidea/puppet-ipa I am wondering if anyone has any success with doing this? Any thing I should consider... any gotchas. Thanks! -- Brent S. Clark NOC Engineer 2580 55th St. | Boulder, Colorado 80301 www.tendrilinc.com http://www.tendrilinc.com/ | blog http://www.tendrilinc.com/news-room/blog/ http://www.tendrilinc.com/ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA client installation for Solaris 11.
Dmitri Pal wrote:
On 04/10/2014 12:18 PM, quest monger wrote:
Sorry about that. So I am Looking at the Solaris 10 client
documentation here -
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html
It says do the following on Solaris client -
ldapclient manual
...
-a proxyPassword={NS1}fbc123a92116812
...
Whats that proxyPassword for?
I suspect that it is a password that corresponds to the proxy user.
The client component on Solaris (pure speculation on my side) seems to
use proxy user to connect to LDAP server and do some operations for the
host. It is similar to SSSD but SSSD does not use passwords, it uses
keytabs if talks to IPA.
There are a number of different profile levels available, see
http://docs.oracle.com/cd/E23824_01/html/821-1455/ldapsecure-66.html#ldapsecure-74
proxy is usually a shared account that the Solaris box uses to
authenticate to the LDAP server.
Solaris uses passwords but to prevent them from being stored in
configuration in clear the are obfuscated with the NS1 method
http://stuff.iain.cx/2008/05/03/ns103eb2365be169abbe3a45088a10a/
I suspect there should be some tool on Solaris that takes password and
creates an obfuscated string like this.
I didn't experiment using a proxy password inside a profile. I'll bet
that if you manually enroll a client then you can dig out the password
on that local system and store that in the profile.
There is also a self level which uses Kerberos. I've never used it
myself (it may be newer than my experience with Solaris) but there are
some fairly detailed docs on it at
http://docs.oracle.com/cd/E23824_01/html/821-1455/clientsetup-49.html#gdzpl
rob
Thanks
Dmitri
Thanks.
On Thu, Apr 10, 2014 at 12:09 PM, Dmitri Pal d...@redhat.com
mailto:d...@redhat.com wrote:
On 04/10/2014 11:41 AM, quest monger wrote:
Thanks Rob, those bug reports help.
One more question, in the official Solaris 10 documentation, i
see this stuff -
-aproxyPassword={NS1}*fbc123a92116812*
userPassword::*e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ*=
Is there a way to generate that password hash for a new password.
I think that should be part of the documentation, dont want all
Solaris IPA users to be using the same password and corresponding
hash.
Can you rephrase the question?
It is unclear what hash you are asking about.
If you are using IPA you do not need local password hashes.
Thanks.
On Wed, Apr 9, 2014 at 4:36 PM, Rob Crittenden
rcrit...@redhat.com mailto:rcrit...@redhat.com wrote:
quest monger wrote:
I have read through the official documentation here for
Solaris-10 -
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html
I have found a few web posts on how to make it work for
Solaris-11.
Have any of you tried adding a Solaris-11 host to an
existing IPA
server? If so, do you have any
documentation/how-tos/instructions that i
could use to do the same. Any help is appreciated.
I am trying to do this to so I can centralize SSH
authentication for all
my Solaris-11 and Linux hosts.
That is pretty much all we've got. There is a bug open with
some documentation updates,
https://bugzilla.redhat.com/show_bug.cgi?id=815533 and some
more in https://bugzilla.redhat.com/show_bug.cgi?id=801883
We use sssd to help with centralized SSH auth so it probably
won't work as smoothly on Solaris as it does on sssd-based
Linux systems. See sss_ssh_authorizedkeys(1) and
sss_ssh_knownhostsproxy(8).
This document describes how it works in IPA
http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
___
Freeipa-users mailing list
Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA client installation for Solaris 11.
On 04/10/2014 01:37 PM, Johan Petersson wrote:
Proxy user is only necessary if you disable anonymous bind on the IPA LDAP.
Example configuration for making Solaris 11 work as an IPA client.
If you want autofs of shared NFS home directory too, let me know and i can
provide it.
I will add this and more to IPA Wiki when i can find the time to go through it
properly and polish away some rough edges.
I hope it can provide some help.
Solaris 11.1 IPA lient configuration.
First make sure that the Solaris 11 machine are using the proper DNS and NTP
servers.
On the IPA server or Client run:
ipa host-add --force --ip-address=192.168.0.1 solaris.example.com
ipa-getkeytab -s ipaserver.example.com -p host/solaris.example.com -k
/tmp/solaris.keytab
Move the keytab to the Solaris machine /etc/krb5/krb5.keytab
Make sure it have the proper owner and permissions:
chown root:sys /etc/krb5/krb5.keytab
chmod 700 /etc/krb5/krb5.keytab
Edit /etc/nsswitch.ldap, replace ldap with dns from the hosts and
ipnodes lines:
hosts: files dns
ipnodes:files dns
Edit /etc/krb5/krb5.conf:
[libdefaults]
default_realm = EXAMPLE.COM
verify_ap_req_nofail = false
[realms]
EXAMPLE.COM = {
kdc = ipaserver.example.com
admin_server = ipaserver.example.com
}
[domain_realm]
example.com = EXAMPLE.COM
.example.com = EXAMPLE.COM
Run the ldapclient with the default DUAProfile.
The -a domainName= example.com is needed so that ldapclient does not stop and
complain about missing nisdomain name.
ldapclient -v init -a profilename=default -a domainName=example.com
ipaserver.example.com
In Solaris 11.1 the pam configuration have changed but for simplicity i still
use the /etc/pam.conf:
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_cred.so.1
login auth sufficient pam_krb5.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth sufficient pam_krb5.so.1
other auth required pam_unix_auth.so.1
other account requisite pam_roles.so.1
other account requiredpam_unix_account.so.1
other account requiredpam_krb5.so.1
other password requisite pam_authtok_check.so.1 force_check
other password sufficient pam_krb5.so.1
other password required pam_authtok_store.so.1
I smell a HowTo wiki page...
From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on
behalf of Rob Crittenden [rcrit...@redhat.com]
Sent: Thursday, April 10, 2014 19:04
To: d...@redhat.com; quest monger
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA client installation for Solaris 11.
Dmitri Pal wrote:
On 04/10/2014 12:18 PM, quest monger wrote:
Sorry about that. So I am Looking at the Solaris 10 client
documentation here -
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html
It says do the following on Solaris client -
ldapclient manual
...
-a proxyPassword={NS1}fbc123a92116812
...
Whats that proxyPassword for?
I suspect that it is a password that corresponds to the proxy user.
The client component on Solaris (pure speculation on my side) seems to
use proxy user to connect to LDAP server and do some operations for the
host. It is similar to SSSD but SSSD does not use passwords, it uses
keytabs if talks to IPA.
There are a number of different profile levels available, see
http://docs.oracle.com/cd/E23824_01/html/821-1455/ldapsecure-66.html#ldapsecure-74
proxy is usually a shared account that the Solaris box uses to
authenticate to the LDAP server.
Solaris uses passwords but to prevent them from being stored in
configuration in clear the are obfuscated with the NS1 method
http://stuff.iain.cx/2008/05/03/ns103eb2365be169abbe3a45088a10a/
I suspect there should be some tool on Solaris that takes password and
creates an obfuscated string like this.
I didn't experiment using a proxy password inside a profile. I'll bet
that if you manually enroll a client then you can dig out the password
on that local system and store that in the profile.
There is also a self level which uses Kerberos. I've never used it
myself (it may be newer than my experience with Solaris) but there are
some fairly detailed docs on it at
http://docs.oracle.com/cd/E23824_01/html/821-1455/clientsetup-49.html#gdzpl
rob
Thanks
Dmitri
Thanks.
On Thu, Apr 10, 2014 at 12:09 PM, Dmitri Pal d...@redhat.com
mailto:d...@redhat.com wrote:
On 04/10/2014 11:41 AM, quest monger wrote:
Thanks Rob, those bug reports help.
One more question, in the official
Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials
SELinux is disabled, I changed the permissions back to the old ones and I have the problem again, although as root I can kinit as myself and can run commands. But not as the regular user. Do you have any strace examples to share? [root@replicahostname /tmp]# ll -Za drwxrwxrwt. rootrootsystem_u:object_r:tmp_t:s0 . dr-xr-xr-x. rootrootsystem_u:object_r:root_t:s0 .. -rw--- rkelly rkelly ?.bash_history drwxrwxrwt rootroot?.ICE-unix drwxrwxr-x rkelly rkelly ?.ipa -r rootroot?krb5cc_0 -r xs05144 xs05144 ? krb5cc_159920_u5RRhd -r rkelly rkelly ? krb5cc_159910_CUkupo -r rkelly rkelly ? krb5cc_159910_ZekyY0 -r apache apache ?krb5cc_48 = [root@replicahostname /tmp]# klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_159910_CUkupo) [root@liipaxs007p /tmp]# cat /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted Thank You, Rashard Kelly From: Sumit Bose sb...@redhat.com To: rashard.ke...@sita.aero Cc: freeipa-users@redhat.com Date: 04/10/2014 12:31 PM Subject:Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials On Thu, Apr 10, 2014 at 11:55:05AM -0400, rashard.ke...@sita.aero wrote: I can run commands after changing the permissions on the files, but why is it generating files that are not world readable? [rkelly@replicahostname ~]$ ll total 84 -rw-r--r-- 1 rootroot 2428 Apr 9 22:34 krb5cc_0 -rw-r--r-- 1 xs05144 xs05144 1146 Apr 3 16:10 krb5cc_159920_u5RRhd -rw-r--r-- 1 rkelly rkelly569 Apr 10 15:14 krb5cc_159910_CUkupo -rw-r--r-- 1 rkelly rkelly 1873 Apr 9 23:40 krb5cc_159910_ZekyY0 -rw-r--r-- 1 apache apache662 Apr 10 06:02 krb5cc_48 Please don't do this, the credential cache files are similar to your password, only the user itself should be allowed to read it. When you use ls with the -Z option there is a '?' where the SELinux context should be printed. Maybe there are issues with your SELinux setup which prevent access to the ccache files? Can you try SELinux in permissive mode? If there are still issues running klist which strace might give some more details why the ccache file cannot be read. HTH bye, Sumit [rkelly@replicahostname ~]$ klist Ticket cache: FILE:/tmp/krb5cc_159910_CUkupo Default principal: rkelly@DOMAIN Valid starting ExpiresService principal 04/10/14 15:14:40 04/11/14 15:14:40 krbtgt/IPA2.DC.SITA.AERO@DOMAIN [rkelly@replicahostname ~]$ ipa user-find kelly -- 1 user matched -- User login: rkelly First name: Rashard Last name: KElly Home directory: /home/rkelly Login shell: /bin/sh Email address: rkelly@domain UID: 159910 GID: 159910 Account disabled: False Password: True Kerberos keys available: True Number of entries returned 1 Thank You, Rashard Kelly From: rashard.ke...@sita.aero To: Alexander Bokovoy aboko...@redhat.com Cc: freeipa-users@redhat.com Date: 04/10/2014 08:42 AM Subject:Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials Sent by:freeipa-users-boun...@redhat.com The krb5 files are not readable by everyone. There are multiple krb5 files in tmp, should they automatically be readable by all? BTW our users do not have home directories if that makes a difference. [rkelly@replicahostname ~]$ ls -lZ /tmp |grep krb -rw--- rootroot?krb5cc_0 -rw--- xs05144 xs05144 ? krb5cc_159920_u5RRhd -rw--- rkelly rkelly ? krb5cc_159910_oKtZFE -rw--- rkelly rkelly ? krb5cc_159910_ZekyY0 -rw--- apache apache ?krb5cc_48 ipa-server-selinux-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 ipa-server-3.0.0-37.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 ipa-python-3.0.0-37.el6.x86_64 ipa-admintools-3.0.0-37.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch [rkelly@replicahostname ~]$ cat /proc/mounts | grep /tmp
Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials
On Thu, Apr 10, 2014 at 02:32:06PM -0400, rashard.ke...@sita.aero wrote: SELinux is disabled, I changed the permissions back to the old ones and I have the problem again, although as root I can kinit as myself and can run commands. But not as the regular user. Do you have any strace examples to share? [root@replicahostname /tmp]# ll -Za drwxrwxrwt. rootrootsystem_u:object_r:tmp_t:s0 . dr-xr-xr-x. rootrootsystem_u:object_r:root_t:s0 .. -rw--- rkelly rkelly ?.bash_history drwxrwxrwt rootroot?.ICE-unix drwxrwxr-x rkelly rkelly ?.ipa -r rootroot?krb5cc_0 -r xs05144 xs05144 ? krb5cc_159920_u5RRhd -r rkelly rkelly ? krb5cc_159910_CUkupo -r rkelly rkelly ? krb5cc_159910_ZekyY0 -r apache apache ?krb5cc_48 = [root@replicahostname /tmp]# klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_159910_CUkupo) strace -o /tmp/klist.out -s 512 klist The needed output will be in /tmp/klist.out. bye, Sumit [root@liipaxs007p /tmp]# cat /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted Thank You, Rashard Kelly From: Sumit Bose sb...@redhat.com To: rashard.ke...@sita.aero Cc: freeipa-users@redhat.com Date: 04/10/2014 12:31 PM Subject:Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials On Thu, Apr 10, 2014 at 11:55:05AM -0400, rashard.ke...@sita.aero wrote: I can run commands after changing the permissions on the files, but why is it generating files that are not world readable? [rkelly@replicahostname ~]$ ll total 84 -rw-r--r-- 1 rootroot 2428 Apr 9 22:34 krb5cc_0 -rw-r--r-- 1 xs05144 xs05144 1146 Apr 3 16:10 krb5cc_159920_u5RRhd -rw-r--r-- 1 rkelly rkelly569 Apr 10 15:14 krb5cc_159910_CUkupo -rw-r--r-- 1 rkelly rkelly 1873 Apr 9 23:40 krb5cc_159910_ZekyY0 -rw-r--r-- 1 apache apache662 Apr 10 06:02 krb5cc_48 Please don't do this, the credential cache files are similar to your password, only the user itself should be allowed to read it. When you use ls with the -Z option there is a '?' where the SELinux context should be printed. Maybe there are issues with your SELinux setup which prevent access to the ccache files? Can you try SELinux in permissive mode? If there are still issues running klist which strace might give some more details why the ccache file cannot be read. HTH bye, Sumit [rkelly@replicahostname ~]$ klist Ticket cache: FILE:/tmp/krb5cc_159910_CUkupo Default principal: rkelly@DOMAIN Valid starting ExpiresService principal 04/10/14 15:14:40 04/11/14 15:14:40 krbtgt/IPA2.DC.SITA.AERO@DOMAIN [rkelly@replicahostname ~]$ ipa user-find kelly -- 1 user matched -- User login: rkelly First name: Rashard Last name: KElly Home directory: /home/rkelly Login shell: /bin/sh Email address: rkelly@domain UID: 159910 GID: 159910 Account disabled: False Password: True Kerberos keys available: True Number of entries returned 1 Thank You, Rashard Kelly From: rashard.ke...@sita.aero To: Alexander Bokovoy aboko...@redhat.com Cc: freeipa-users@redhat.com Date: 04/10/2014 08:42 AM Subject:Re: [Freeipa-users] ipa: ERROR: did not receive Kerberos credentials Sent by:freeipa-users-boun...@redhat.com The krb5 files are not readable by everyone. There are multiple krb5 files in tmp, should they automatically be readable by all? BTW our users do not have home directories if that makes a difference. [rkelly@replicahostname ~]$ ls -lZ /tmp |grep krb -rw--- rootroot?krb5cc_0 -rw--- xs05144 xs05144 ? krb5cc_159920_u5RRhd -rw--- rkelly rkelly ? krb5cc_159910_oKtZFE -rw--- rkelly rkelly ? krb5cc_159910_ZekyY0 -rw--- apache apache ?krb5cc_48 ipa-server-selinux-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 ipa-server-3.0.0-37.el6.x86_64
[Freeipa-users] Rekey Self-signed CA
I feel dumb, but I cannot seem to find anything about this. How do I rekey the self-signed CA cert for IdM/IPA? It seems like it should be something simple, but I’m not finding anything. CentOS 6.5 install. If you’ve got a place to point me towards, that would be wonderful. Thanks, Greg Harris ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Rekey Self-signed CA
Greg Harris wrote: I feel dumb, but I cannot seem to find anything about this. How do I rekey the self-signed CA cert for IdM/IPA? It seems like it should be something simple, but I’m not finding anything. CentOS 6.5 install. If you’ve got a place to point me towards, that would be wonderful. Need more information on your installation, including the version. Are you running the IPA CA? And what do you mean by re-key (and why do you want to)? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External Collaboration Domains
Close. The problem is to expose kerberized services in the local realm to users holding foreign credentials, supporting SSO wherever possible. This includes file sharing via NFS, kerberized web apps, ssh logins, and anything else the local realm has to offer. SSSD can handle ssh logins (if one considers it handled to transmit the password over the wire and abandon SSO), but cannot handle the former two. This is already handled with the trusts feature with AD. It is handled by SSO and using Kerberos ticket renegotiation between two domains. The similar approach would work for IPA to IPA and IPA to Kerberos. In the IPA to IPA case we will have authorization data in the ticket that would help with this. I am sorry I fail to see a driver and use case here. But may be I am missing something obvious. Trusts are only feasible between tightly coordinated realms and with the involvement of admins. The use case is a collaboration realm, where users (not admins) drive the connections between realms. This precipitates everything in the proposal. If the user is coming from an AD realm, there may not be a trust, and it may be inappropriate to have an admin form one if there are only three or four users binding the two realms together. The AD realm may be behind the institutional firewall and the KDC inaccessible, making PKINIT a good choice. Perhaps kx509 certificates are not available from the home realm, making OpenID or SAML a good choice. A theme in your previous message was that some use case is already covered because the admin can explicitly take some action to handle it, and each instance (each new trust) needs to be individually created and then managed. The point of this RFE is that the admin can set up a realm which responds to how users travel from realm to realm, offering both flexibility for the manner in which users authenticate and consistency for the services offered by the realm. It's a different mindset that makes the use case invisible. :) Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External Collaboration Domains
On 04/10/2014 05:40 PM, Nordgren, Bryce L -FS wrote: Close. The problem is to expose kerberized services in the local realm to users holding foreign credentials, supporting SSO wherever possible. This includes file sharing via NFS, kerberized web apps, ssh logins, and anything else the local realm has to offer. SSSD can handle ssh logins (if one considers it handled to transmit the password over the wire and abandon SSO), but cannot handle the former two. This is already handled with the trusts feature with AD. It is handled by SSO and using Kerberos ticket renegotiation between two domains. The similar approach would work for IPA to IPA and IPA to Kerberos. In the IPA to IPA case we will have authorization data in the ticket that would help with this. I am sorry I fail to see a driver and use case here. But may be I am missing something obvious. Trusts are only feasible between tightly coordinated realms and with the involvement of admins. The use case is a collaboration realm, where users (not admins) drive the connections between realms. This precipitates everything in the proposal. If the user is coming from an AD realm, there may not be a trust, and it may be inappropriate to have an admin form one if there are only three or four users binding the two realms together. The AD realm may be behind the institutional firewall and the KDC inaccessible, making PKINIT a good choice. Perhaps kx509 certificates are not available from the home realm, making OpenID or SAML a good choice. A theme in your previous message was that some use case is already covered because the admin can explicitly take some action to handle it, and each instance (each new trust) needs to be individually created and then managed. The point of this RFE is that the admin can set up a realm which responds to how users travel from realm to realm, offering both flexibility for the manner in which users authenticate and consistency for the services offered by the realm. It's a different mindset that makes the use case invisible. :) I guess we just do not see this scenario in practice yet. The users that come from an external realm would come via SAML or similar and interact with a service provided by the local realm. In this case an external user needs to be mapped to the role by the service. Such user does not need to have a special user account, principal, UID/GID as he is not going to access the vanilla services and infrastructure on the low level. He is sort of guest, a tenant, and will be handle by a provided service rather than infra. The service can cache the user information for future but not more than that. Sorry I have a mindset that suggest that allowing external users to auto-materialize in my internal enterprise domain servicing my infa is a bad idea. May be it comes from the deep belief that the role of IdM is to only serve local identities inside the local namespace and federate with other namespaces using trusts or SAML and similar. Can you give me an example of a real world scenario when a local domain would welcome user accounts to be synthesized out of the thin air? Thanks Dmitri Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Rekey Self-signed CA
Greg Harris wrote: Rob, Thanks for the quick response. It’s version 3.0, as included in CentOS 6.5 EPEL. Yes, I’m running the IPA CA, installed as a self-signed setup. By rekey, I mean generating a new Public/Private key pair for the CA certificate, and then subsequently rekeying all of the certs below. Main reason? Heartbleed. No worries then. The IPA CA (dogtag) uses NSS for crypto so there is no way the CA private key could have been exposed. If you've issued SSL certs from the IPA CA for services running OpenSSL you could re-issue those to be on the safe side, but IPA itself uses only NSS on its servers. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] add a cert of .net insetad of .com error ?
Dear all: I added *.abc.net cet to certutil -d /etc/httpd/alias and /etc/dirsrv/slapd-ABC-COM But error comes out after when i login the UI of service and cick in entry . cannot connect to 'https://cert1.abc.com:443/ca/agent/ca/displayBySerial': [Errno -12276] (SSL_ERROR_BAD_CERT_DOMAIN) Unable to communicate securely with peer: requested domain name does not match the server's certificate. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
