Re: [Freeipa-users] weird behavior on centos 6

[Dmitri Pal]

On 05/14/2014 06:12 PM, Carl E. Ma wrote:

Hello,

Recently I realized our centos 6 freeipa clients hangs randomly. With 
some research, the issue is related to autofs bug, which was mentioned 
year ago - Automount fails for IPA user when kerberos ticket is 
expired, ssh hangs (https://fedorahosted.org/freeipa/ticket/2980).  
This ticket was closed with comment - "closed defect: invalid".


My workaround is extending  ticket_lifetime to 24h and renew_lifetime 
to 365d. I wonder whether there is better solution or some insights of 
this bug.


Thanks,

carl




___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



Read about GSS proxy.

--
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] weird behavior on centos 6

[Carl E. Ma]

Hello,

Recently I realized our centos 6 freeipa clients hangs randomly. With 
some research, the issue is related to autofs bug, which was mentioned 
year ago - Automount fails for IPA user when kerberos ticket is expired, 
ssh hangs (https://fedorahosted.org/freeipa/ticket/2980).  This ticket 
was closed with comment - "closed defect: invalid".


My workaround is extending  ticket_lifetime to 24h and renew_lifetime to 
365d. I wonder whether there is better solution or some insights of this 
bug.


Thanks,

carl




___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] External collaboration edits

[Dmitri Pal]

On 04/19/2014 07:46 PM, Nordgren, Bryce L -FS wrote:


I've run out of time for today, but the external collaboration pages 
are slowly evolving.


http://www.freeipa.org/page/External_Users_in_IPA

Dimitri observed that my RFE page was too long. I observe it also has 
too much stuff unrelated to the actual meat of the RFE. So I factored 
out most of the Kerberos stuff into a different page. I also tried to 
focus the RFE to just creating entries in LDAP for external users so 
they can: a] participate in POSIX groups; and b] have locally-defined 
POSIX attributes.


http://www.freeipa.org/page/Collaboration_with_Kerberos

This is where all the Kerberos stuff went. I also added  in "Option A" 
from Petr's email. Option B will come along later, when I pick this up 
again. Mechanism three has more to do with Ipsilon than IPA, and basic 
functions required of the Ipsilon gateway server are articulated there 
(regardless of the particular authentication method.)


Send comments to the list. I really appreciate Option A! Send more 
stuff I didn't think of.




Hello,


I finally read the pages, sorry for the delay. great writeup!

Here are some comments.

1) You are right that we need to have a record in IPA to be able to have 
a DN and take over some of the posix attributes. We already have this 
use case and this is a high priority. We call it views: 
https://fedorahosted.org/freeipa/ticket/3979
Once this is implemented we will have mechanism to have a local entry 
without credential for the external user.
2) The second issue is provisioning as automatic as possible. And this 
is where there will be some issues.

If we want to leverage Kerberos trusts then two things should happen:
a) the trust should first be established
b) the home realm should be accessible for the KDC in the collaboration 
domain.
This rises practical operational questions about what is the home 
domain. If the home domain is another collaboration domain then user is 
natively have been created in that domain and has his credential in that 
domain. Hm but that violates the idea that the collaboration domains 
have external "auto-provisioned users". If the home domain is the 
internal domain than most likely the cross forest trust can't be 
established because admin of the internal domain would not want to 
expose his domain to somebody's external domain on the internet.

So IMO the kerberos based auto-provisioning falls apart.

However if we use a gateway that would allow a person to self register 
and use technologies similar to OpenID then we would be able to create 
his own account. The gateway would check that the user is from some 
trusted source that is configured for that domain. We would have to 
figure that part out. But IMO this component is external to IPA. It is a 
similar gateway to Ipsilon. I suspect that as we move forward Ipsilon 
will transform from an IdP server to being a collection of "gateway 
services". One would be able to deploy IdP instances, Kerberos -> cert 
service, account registration service etc.


This would rely on some of the functionality in IPA but can evolve 
independently.
IMO if we go this path and you are interested in contributing to this 
effort we can start prototyping such service.
We can start simple: create a service that allows one to authenticate 
using google or facebook and once user authenticated agains one of them 
call an ipa user-add against IPA.

That would be a good first step towards what you want to accomplish.
Then it can be enhanced to redirect to an external IdP (Ipsilon). Then 
the setup will be:


* User connects to the self registration portal.
* Portal reditrects him to the IdP that is configured for the portal
* IdP performas an authentication against user home domain and creates 
assertion

* Assertion is presented to the registration portal
* The portal gets user infor from the assertion and adds a user

It also seems that OpenID connect might be quite relevant here.
So exploring how it can be used in in conjunction with registration 
portal would be another path.


3) The problem of the credential yet stays open. If the user can be 
created in different ways it might not be quite easy for the user to 
know or remember that he must use his kerberos/Google/facebook or other 
credential wit ha specific domain. May be we should consider creating a 
full user also with a password or OTP token to access the collaboration 
domain. Then user would always know that he needs to use his token. I 
wonder if actually just OTP would be a good option in this case. It can 
be provisioned to the freeOTP app at the moment of the user registration.


Bottom line: let us do practical steps in the right direction. The whole 
project seems to have too many weak points to try to solve it as a 
single use case.
I would rather focus on building technologies that would gradually make 
life of collaboration domains easier and get there over time.



Thanks
Dmitri


Bryce





This electronic messa

Re: [Freeipa-users] DNS SOA Records

[Petr Spacek]

On 13.5.2014 21:32, Dmitri Pal wrote:

On 05/13/2014 02:12 PM, Bob wrote:

I ran

ipa dnszone-mod vh1.vzwnet.com 
--update-policy="grant bob-key name test.vh1.vzwnet.com.;"

I then execute the nsupdate:

[root@nj51rhidms16v ~]# ./bobtest.sh
; TSIG error with server: tsig indicates error
update failed: NOTAUTH(BADKEY)


[root@nj51rhidms16v ~]# cat ./bobtest.sh
#!/bin/ksh
#
keyfile=bob-key:hkVEYuIRUGaytJRHPd0tww==
print "update add test.vh1.vzwnet.com  90 CNAME
txslxngda5.nss.vzwnet.com \n"|nsupdate -y
$keyfile

[root@nj51rhidms16v log]# tail daemon
May 13 03:20:04 nj51rhidms16v [sssd[ldap_child[11987]]]: Error processing
keytab file [default]: Principal
[host/nj51rhidms16v.nss.vzwnet@ipa.nss.vzwnet.com
] was not found.
Unable to create GSSAPI-encrypted LDAP connection.
May 13 03:20:04 nj51rhidms16v [sssd[ldap_child[11987]]]: Error writing to
key table
May 13 04:45:42 nj51rhidms16v rhnsd[12406]: running program /usr/sbin/rhn_check
May 13 08:45:42 nj51rhidms16v rhnsd[12962]: running program /usr/sbin/rhn_check
May 13 12:08:55 nj51rhidms16v [sssd[ldap_child[13470]]]: Error processing
keytab file [default]: Principal
[host/nj51rhidms16v.nss.vzwnet@ipa.nss.vzwnet.com
] was not found.
Unable to create GSSAPI-encrypted LDAP connection.
May 13 12:08:55 nj51rhidms16v [sssd[ldap_child[13470]]]: Error writing to
key table
May 13 12:45:42 nj51rhidms16v rhnsd[13543]: running program /usr/sbin/rhn_check
May 13 14:07:59 nj51rhidms16v named[27438]: client 10.194.96.47#15739:
All errors above are irrelevant to nsupdate. It points to an problem with SSSD 
configuration but this should not affect nsupdate with TSIG at all.



request has invalid signature: TSIG bob-key: tsig verify failure (BADKEY)
May 13 14:11:24 nj51rhidms16v [sssd[ldap_child[13785]]]: Error processing
My best guess is that you have modified update-policy to reference key 
"bob-key" but the key is not defined in named.conf.


Unfortunately, IPA doesn't support TSIG keys in LDAP. You have to define all 
keys on all servers in named.conf manually:


Add something like:

key "bob-key" {
  algorithm hmac-md5;
  secret "";
};

and restart named.

Then it should work.

If you want to see support for TSIG keys in LDAP then please open a FreeIPA 
ticket:

https://fedorahosted.org/freeipa/newticket

To speed things up, please describe your use case (in detail) and propose user 
interface.



Also, please note that hmac-md5 is not "the most secure algorithm in the 
world". GSS-TSIG should be more secure. I would recommend you to gradually 
migrate from TSIG to GSS-TSIG.


Have a nice day!

--
Petr^2 Spacek

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users