Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

[Rob Crittenden]

Christian Hernandez wrote:

Looks like I've narrowed it down to...something...

[r...@ipa1.la3.4over.com  ~]#
ipa-replica-manage list ipa1.gln.4over.com 
Failed to get data from 'ipa1.gln.4over.com
': Invalid credentials SASL(-13):
authentication failure: GSSAPI Failure: gss_accept_sec_context
[r...@ipa1.la3.4over.com  ~]#
ipa-replica-manage list ipa1.da2.4over.com 
ipa1.gln.4over.com : replica
ipa1.la3.4over.com : replica
[r...@ipa1.la3.4over.com  ~]#
ipa-replica-manage list $(hostname)
ipa1.da2.4over.com : replica
ipa1.gln.4over.com : replica
[r...@ipa1.la3.4over.com  ~]# rpm -qa
|egrep '389|ipa'
ipa-admintools-3.0.0-26.el6_4.2.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-python-3.0.0-26.el6_4.2.x86_64
libipa_hbac-python-1.9.2-82.4.el6_4.x86_64
389-ds-base-libs-1.2.11.15-12.el6_4.x86_64
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-server-selinux-3.0.0-26.el6_4.2.x86_64
libipa_hbac-1.9.2-82.4.el6_4.x86_64
ipa-client-3.0.0-26.el6_4.2.x86_64
389-ds-base-1.2.11.15-12.el6_4.x86_64
ipa-server-3.0.0-26.el6_4.2.x86_64

Although when I try to remove the replication agreement...I can't =\

[r...@ipa1.la3.4over.com  ~]#
ipa-replica-manage disconnect $(hostname) ipa1.gln.4over.com

Failed to get list of agreements from 'ipa1.gln.4over.com
': Invalid credentials SASL(-13):
authentication failure: GSSAPI Failure: gss_accept_sec_context


A couple of things to try:

- Check the KDC logs on the various hosts to see what error it is 
logging trying to get a ticket.
- kdestroy and let ipa-replica-manage prompt you for the DM password, or 
pass it via -p on the command-line


The first might tell you why you are seeing an auth failure, the second 
should show the status of replication and let you run other commands. 
I'm not sure that disconnecting is going to fix anything though. I'm not 
sure what it is you're trying to do there.


rob

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

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

[Christian Hernandez]

Looks like I've narrowed it down to...something...

[r...@ipa1.la3.4over.com ~]# ipa-replica-manage list ipa1.gln.4over.com
Failed to get data from 'ipa1.gln.4over.com': Invalid credentials
SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
[r...@ipa1.la3.4over.com ~]# ipa-replica-manage list ipa1.da2.4over.com
ipa1.gln.4over.com: replica
ipa1.la3.4over.com: replica
[r...@ipa1.la3.4over.com ~]# ipa-replica-manage list $(hostname)
ipa1.da2.4over.com: replica
ipa1.gln.4over.com: replica
[r...@ipa1.la3.4over.com ~]# rpm -qa |egrep '389|ipa'
ipa-admintools-3.0.0-26.el6_4.2.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-python-3.0.0-26.el6_4.2.x86_64
libipa_hbac-python-1.9.2-82.4.el6_4.x86_64
389-ds-base-libs-1.2.11.15-12.el6_4.x86_64
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-server-selinux-3.0.0-26.el6_4.2.x86_64
libipa_hbac-1.9.2-82.4.el6_4.x86_64
ipa-client-3.0.0-26.el6_4.2.x86_64
389-ds-base-1.2.11.15-12.el6_4.x86_64
ipa-server-3.0.0-26.el6_4.2.x86_64

Although when I try to remove the replication agreement...I can't =\

[r...@ipa1.la3.4over.com ~]# ipa-replica-manage disconnect $(hostname)
ipa1.gln.4over.com
Failed to get list of agreements from 'ipa1.gln.4over.com': Invalid
credentials SASL(-13): authentication failure: GSSAPI Failure:
gss_accept_sec_context


Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com 
www.4over.com 


On Mon, Apr 15, 2013 at 6:58 PM, Christian Hernandez
wrote:

> Yes; I verified that both forward and reverse DNS match on all nodes.
>
>
> Thank you,
>
> Christian Hernandez
> 1225 Los Angeles Street
> Glendale, CA 91204
> Phone: 877-782-2737 ext. 4566
> Fax: 818-265-3152
> christi...@4over.com 
> www.4over.com 
>
>
> On Mon, Apr 15, 2013 at 6:21 PM, Dmitri Pal  wrote:
>
>>  On 04/15/2013 08:41 PM, Christian Hernandez wrote:
>>
>> Yup, looks like replication is broken =\
>>
>> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage disconnect
>> ipa1.la3.4over.com
>> Failed to get list of agreements from 'ipa1.la3.4over.com': Invalid
>> credentials SASL(-13): authentication failure: GSSAPI Failure:
>> gss_accept_sec_context
>>
>> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com
>> Failed to get data from 'ipa1.la3.4over.com': Invalid credentials
>> SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
>>
>> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list
>> ipa1.la3.4over.com: master
>> ipa1.gln.4over.com: master
>> ipa1.da2.4over.com: master
>>
>>
>>
>> Do the machines resolve each other correctly?
>>
>>
>>
>>
>> Thank you,
>>
>> Christian Hernandez
>>  1225 Los Angeles Street
>> Glendale, CA 91204
>> Phone: 877-782-2737 ext. 4566
>> Fax: 818-265-3152
>> christi...@4over.com 
>> www.4over.com 
>>
>>
>> On Mon, Apr 15, 2013 at 4:58 PM, Christian Hernandez <
>> christi...@4over.com> wrote:
>>
>>>  Okay,
>>>
>>> So I tried to update to the newest version. Update went okay and users
>>> can authenticate (as far as I can tell)...
>>>
>>> But I think may be replication broke?
>>>
>>> [r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync  --from=
>>> ipa1.gln.4over.com
>>> Invalid password
>>>
>>>  Any ideas?
>>>
>>>
>>> Thank you,
>>>
>>> Christian Hernandez
>>>  1225 Los Angeles Street
>>> Glendale, CA 91204
>>> Phone: 877-782-2737 ext. 4566
>>> Fax: 818-265-3152
>>> christi...@4over.com 
>>> www.4over.com 
>>>
>>>
>>>   On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek wrote:
>>>
 On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
 > There are some odd errors in ldap_child.log but it seems to cover a
 > later period than the other logs (not being able to bind using its
 > keytab is a bad thing).
 >
 > I think what you'll want to do, and this may be relatively tough, is
 > try to correlate these failures with the 389-ds access log and the
 > KDC logs to see if there are equivalent failures at around the same
 > times.

  I agree, the ldap_child failing usually indicates an issue with the
 keytab and/or the KDC. The ldap_child functionality is roughly
 equivalent to
 "kinit -k".

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

>>>
>>>
>>
>>
>> ___
>> Freeipa-users mailing 
>> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>>
>> --
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager for IdM portfolio
>> Red Hat Inc.
>>
>>
>> ---
>> Looking to carve out IT costs?www.redha

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

[Christian Hernandez]

Yes; I verified that both forward and reverse DNS match on all nodes.


Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com 
www.4over.com 


On Mon, Apr 15, 2013 at 6:21 PM, Dmitri Pal  wrote:

>  On 04/15/2013 08:41 PM, Christian Hernandez wrote:
>
> Yup, looks like replication is broken =\
>
> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage disconnect
> ipa1.la3.4over.com
> Failed to get list of agreements from 'ipa1.la3.4over.com': Invalid
> credentials SASL(-13): authentication failure: GSSAPI Failure:
> gss_accept_sec_context
>
> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com
> Failed to get data from 'ipa1.la3.4over.com': Invalid credentials
> SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
>
> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list
> ipa1.la3.4over.com: master
> ipa1.gln.4over.com: master
> ipa1.da2.4over.com: master
>
>
>
> Do the machines resolve each other correctly?
>
>
>
>
> Thank you,
>
> Christian Hernandez
>  1225 Los Angeles Street
> Glendale, CA 91204
> Phone: 877-782-2737 ext. 4566
> Fax: 818-265-3152
> christi...@4over.com 
> www.4over.com 
>
>
> On Mon, Apr 15, 2013 at 4:58 PM, Christian Hernandez  > wrote:
>
>>  Okay,
>>
>> So I tried to update to the newest version. Update went okay and users
>> can authenticate (as far as I can tell)...
>>
>> But I think may be replication broke?
>>
>> [r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync  --from=
>> ipa1.gln.4over.com
>> Invalid password
>>
>>  Any ideas?
>>
>>
>> Thank you,
>>
>> Christian Hernandez
>>  1225 Los Angeles Street
>> Glendale, CA 91204
>> Phone: 877-782-2737 ext. 4566
>> Fax: 818-265-3152
>> christi...@4over.com 
>> www.4over.com 
>>
>>
>>   On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek wrote:
>>
>>> On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
>>> > There are some odd errors in ldap_child.log but it seems to cover a
>>> > later period than the other logs (not being able to bind using its
>>> > keytab is a bad thing).
>>> >
>>> > I think what you'll want to do, and this may be relatively tough, is
>>> > try to correlate these failures with the 389-ds access log and the
>>> > KDC logs to see if there are equivalent failures at around the same
>>> > times.
>>>
>>>  I agree, the ldap_child failing usually indicates an issue with the
>>> keytab and/or the KDC. The ldap_child functionality is roughly
>>> equivalent to
>>> "kinit -k".
>>>
>>> ___
>>> Freeipa-users mailing list
>>> Freeipa-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>
>>
>
>
> ___
> Freeipa-users mailing 
> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> ---
> Looking to carve out IT costs?www.redhat.com/carveoutcosts/
>
>
> ___
> 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 not authenticating - SSSD issue maybe

[Dmitri Pal]

On 04/15/2013 08:41 PM, Christian Hernandez wrote:
> Yup, looks like replication is broken =\
>
> [r...@ipa1.gln.4over.com  ipa]#
> ipa-replica-manage disconnect ipa1.la3.4over.com
> 
> Failed to get list of agreements from 'ipa1.la3.4over.com
> ': Invalid credentials SASL(-13):
> authentication failure: GSSAPI Failure: gss_accept_sec_context
>
> [r...@ipa1.gln.4over.com  ipa]#
> ipa-replica-manage list ipa1.la3.4over.com 
> Failed to get data from 'ipa1.la3.4over.com
> ': Invalid credentials SASL(-13):
> authentication failure: GSSAPI Failure: gss_accept_sec_context
>
> [r...@ipa1.gln.4over.com  ipa]#
> ipa-replica-manage list
> ipa1.la3.4over.com : master
> ipa1.gln.4over.com : master
> ipa1.da2.4over.com : master


Do the machines resolve each other correctly?

>
>
> Thank you,
>
> Christian Hernandez
> 1225 Los Angeles Street
> Glendale, CA 91204
> Phone: 877-782-2737 ext. 4566
> Fax: 818-265-3152
> christi...@4over.com 
> >
> www.4over.com   >
>
>
> On Mon, Apr 15, 2013 at 4:58 PM, Christian Hernandez
> mailto:christi...@4over.com>> wrote:
>
> Okay,
>
> So I tried to update to the newest version. Update went okay and
> users can authenticate (as far as I can tell)...
>
> But I think may be replication broke?
>
> [r...@ipa1.da2.4over.com  log]#
> ipa-replica-manage force-sync  --from=ipa1.gln.4over.com
>  
> Invalid password
>
> Any ideas?
>
>
> Thank you,
>
> Christian Hernandez
> 1225 Los Angeles Street
> Glendale, CA 91204
> Phone: 877-782-2737 ext. 4566
> Fax: 818-265-3152
> christi...@4over.com 
> >
> www.4over.com   >
>
>
> On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek  > wrote:
>
> On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
> > There are some odd errors in ldap_child.log but it seems to
> cover a
> > later period than the other logs (not being able to bind
> using its
> > keytab is a bad thing).
> >
> > I think what you'll want to do, and this may be relatively
> tough, is
> > try to correlate these failures with the 389-ds access log
> and the
> > KDC logs to see if there are equivalent failures at around
> the same
> > times.
>
> I agree, the ldap_child failing usually indicates an issue
> with the
> keytab and/or the KDC. The ldap_child functionality is roughly
> equivalent to
> "kinit -k".
>
> ___
> 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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-users] User Roles and access in GUI

[Dmitri Pal]

On 04/15/2013 07:42 PM, Chandan Kumar wrote:
>
> I agree it won't be a security feature nor you are doing wrong by not
> adding it. However, it might come as nice to have feature. Let me
> explain you my condition.
>
> We host web application where lot of DNS entries (Public and Internal)
> are created for different kind of requests and features. Now we
> already have a separate DNS server, Separate Manual Linux User/Access
> Control management by puppet. Linux users   ACL have no relationship
> with the web application user (which is internal to the web app). 
>
> So FreeIPA can help me to centralize the Linux user-management as well
> as (Public and Internal) DNS. However, the problem is : traditionally
> the access levels were different for DNS users (support guys) and user
> management (sysadmins). Now bring both system together even the Host
> based access control, sudoers rule everything becomes visible to
> non-sysadmin group.
>
> You are right that every user could query all entries from command
> line and hence it won't help  to secure the system, but not having it
> on GUI may help to avoid "obvious" visibility of the whole directory.
>
> I believe similar GUI "views" could be applied for discussion 
>
> http://osdir.com/ml/freeipa-users/2013-03/msg00218.html
>
> where geographically separate Organization units may share the same
> directory with limited visibility on other branches.
>
>
> Having said that, I am not sure how feasible/logical my view is owing
> to my limited knowledge in 389 directory server and IPA.

I think you are talking about this:
https://fedorahosted.org/freeipa/ticket/217
and somewhat about this https://fedorahosted.org/freeipa/ticket/1313

Would you mind adding the details of your use case to one of those two
tickets?

Alternatively we can start another ticket.
However I think we should have some kind of a complete solution that
covers LDAP, UI and CLI consistently.
Doing it right would be a huge task IMO.
For LDAP we would probably have to implement some kind of "smart" proxy
that would reply only to the requests that user are entitled to. Same
with CLI and UI. But the point is that one configuration should be
respected by all three at the same time. For example if you are not
allowed to manage sudo the sudo commands should not return any data as
well as LDAP searches and there should be no panel in the UI.

I am really reluctant to fix just UI because we would end up different
components of the system behaving differently and it would be hard to
evolve them and maintain.

Thanks
Dmitri

>
> Thanks
> Chandan
>
>
> On Monday, April 15, 2013, Dmitri Pal wrote:
>
> On 04/15/2013 11:11 AM, Chandan Kumar wrote:
>>
>> I think controlling Visibility of tabs would be the best option,
>> if possible, based on Roles as mentioned by Rob. As long as other
>> entries are not visible in UI, even though they have read only
>> access with command line, should be enough.
>>
>
> It would not be a security feature though. Just a convenience
> because the same admin would be able to bind directly to ldap and
> run a search. This is why we did not go this route. Yes we can
> hide panels but it would not mean that the user can't easily get
> that info. So is there really a value in hiding? So far we did not
> see any this is why we did not do it, but may be you have some
> arguments that might convince us that we are wrong. Can you please
> share these arguments with us? 
>
>>
>> On Monday, April 15, 2013, Alexander Bokovoy wrote:
>>
>> On Mon, 15 Apr 2013, Petr Spacek wrote:
>>
>> On 15.4.2013 15:39, Rob Crittenden wrote:
>>
>> There is no easy way to do this. We start with
>> granting all authenticated
>> users read access to the tree with the exception of
>> certain attributes (like
>> passwords).
>>
>> You'd have to start by removing that, then one by one
>> granting read access to
>> the various containers based on, well, something.
>>
>>
>> Would it be possible to create a new role to allow
>> current 'read-all access' and add this role to all users
>> by default?
>>
>> It could be much simpler to change the behaviour with
>> this role, or not? :-)
>>
>> It would affect service accounts (include host/fqdn@REALM)
>> since roles
>> cannot be applied to them, if I remember correctly. We would
>> need to
>> make an exclusive ACI that allows all services to gain read
>> only access...
>>
>> -- 
>> / Alexander Bokovoy
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>>
>> -- 
>>
>> --
>> http://about.me/

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

[Christian Hernandez]

Yup, looks like replication is broken =\

[r...@ipa1.gln.4over.com ipa]# ipa-replica-manage disconnect
ipa1.la3.4over.com
Failed to get list of agreements from 'ipa1.la3.4over.com': Invalid
credentials SASL(-13): authentication failure: GSSAPI Failure:
gss_accept_sec_context

[r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com
Failed to get data from 'ipa1.la3.4over.com': Invalid credentials
SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context

[r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list
ipa1.la3.4over.com: master
ipa1.gln.4over.com: master
ipa1.da2.4over.com: master


Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com 
www.4over.com 


On Mon, Apr 15, 2013 at 4:58 PM, Christian Hernandez
wrote:

> Okay,
>
> So I tried to update to the newest version. Update went okay and users can
> authenticate (as far as I can tell)...
>
> But I think may be replication broke?
>
> [r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync  --from=
> ipa1.gln.4over.com
> Invalid password
>
> Any ideas?
>
>
> Thank you,
>
> Christian Hernandez
> 1225 Los Angeles Street
> Glendale, CA 91204
> Phone: 877-782-2737 ext. 4566
> Fax: 818-265-3152
> christi...@4over.com 
> www.4over.com 
>
>
> On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek  wrote:
>
>> On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
>> > There are some odd errors in ldap_child.log but it seems to cover a
>> > later period than the other logs (not being able to bind using its
>> > keytab is a bad thing).
>> >
>> > I think what you'll want to do, and this may be relatively tough, is
>> > try to correlate these failures with the 389-ds access log and the
>> > KDC logs to see if there are equivalent failures at around the same
>> > times.
>>
>> I agree, the ldap_child failing usually indicates an issue with the
>> keytab and/or the KDC. The ldap_child functionality is roughly equivalent
>> to
>> "kinit -k".
>>
>> ___
>> 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 not authenticating - SSSD issue maybe

[Christian Hernandez]

Okay,

So I tried to update to the newest version. Update went okay and users can
authenticate (as far as I can tell)...

But I think may be replication broke?

[r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync  --from=
ipa1.gln.4over.com
Invalid password

Any ideas?


Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com 
www.4over.com 


On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek  wrote:

> On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
> > There are some odd errors in ldap_child.log but it seems to cover a
> > later period than the other logs (not being able to bind using its
> > keytab is a bad thing).
> >
> > I think what you'll want to do, and this may be relatively tough, is
> > try to correlate these failures with the 389-ds access log and the
> > KDC logs to see if there are equivalent failures at around the same
> > times.
>
> I agree, the ldap_child failing usually indicates an issue with the
> keytab and/or the KDC. The ldap_child functionality is roughly equivalent
> to
> "kinit -k".
>
> ___
> 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] User Roles and access in GUI

[Chandan Kumar]

I agree it won't be a security feature nor you are doing wrong by not
adding it. However, it might come as nice to have feature. Let me explain
you my condition.

We host web application where lot of DNS entries (Public and Internal) are
created for different kind of requests and features. Now we already have a
separate DNS server, Separate Manual Linux User/Access Control management
by puppet. Linux users   ACL have no relationship with the web application
user (which is internal to the web app).

So FreeIPA can help me to centralize the Linux user-management as well as
(Public and Internal) DNS. However, the problem is : traditionally the
access levels were different for DNS users (support guys) and user
management (sysadmins). Now bring both system together even the Host based
access control, sudoers rule everything becomes visible to non-sysadmin
group.

You are right that every user could query all entries from command line and
hence it won't help  to secure the system, but not having it on GUI may
help to avoid "obvious" visibility of the whole directory.

I believe similar GUI "views" could be applied for discussion

http://osdir.com/ml/freeipa-users/2013-03/msg00218.html

where geographically separate Organization units may share the same
directory with limited visibility on other branches.


Having said that, I am not sure how feasible/logical my view is owing to my
limited knowledge in 389 directory server and IPA.

Thanks
Chandan


On Monday, April 15, 2013, Dmitri Pal wrote:

>  On 04/15/2013 11:11 AM, Chandan Kumar wrote:
>
>
>  I think controlling Visibility of tabs would be the best option, if
> possible, based on Roles as mentioned by Rob. As long as other entries are
> not visible in UI, even though they have read only access with command
> line, should be enough.
>
>
> It would not be a security feature though. Just a convenience because the
> same admin would be able to bind directly to ldap and run a search. This is
> why we did not go this route. Yes we can hide panels but it would not mean
> that the user can't easily get that info. So is there really a value in
> hiding? So far we did not see any this is why we did not do it, but may be
> you have some arguments that might convince us that we are wrong. Can you
> please share these arguments with us?
>
>
> On Monday, April 15, 2013, Alexander Bokovoy wrote:
>
>> On Mon, 15 Apr 2013, Petr Spacek wrote:
>>
>>> On 15.4.2013 15:39, Rob Crittenden wrote:
>>>
 There is no easy way to do this. We start with granting all
 authenticated
 users read access to the tree with the exception of certain attributes
 (like
 passwords).

 You'd have to start by removing that, then one by one granting read
 access to
 the various containers based on, well, something.

>>>
>>> Would it be possible to create a new role to allow current 'read-all
>>> access' and add this role to all users by default?
>>>
>>> It could be much simpler to change the behaviour with this role, or not?
>>> :-)
>>>
>> It would affect service accounts (include host/fqdn@REALM) since roles
>> cannot be applied to them, if I remember correctly. We would need to
>> make an exclusive ACI that allows all services to gain read only access...
>>
>> --
>> / Alexander Bokovoy
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>
>
> --
>
> --
> http://about.me/chandank
>
>
>
> ___
> Freeipa-users mailing 
> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> ---
> Looking to carve out IT costs?www.redhat.com/carveoutcosts/
>
>

-- 

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

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

[Jakub Hrozek]

On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
> There are some odd errors in ldap_child.log but it seems to cover a
> later period than the other logs (not being able to bind using its
> keytab is a bad thing).
> 
> I think what you'll want to do, and this may be relatively tough, is
> try to correlate these failures with the 389-ds access log and the
> KDC logs to see if there are equivalent failures at around the same
> times.

I agree, the ldap_child failing usually indicates an issue with the
keytab and/or the KDC. The ldap_child functionality is roughly equivalent to
"kinit -k".

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

Re: [Freeipa-users] LDAP authentication for 3rd party

[Peter Brown]

On 12 April 2013 23:59, Rich Megginson  wrote:

>  On 04/11/2013 11:58 PM, Peter Brown wrote:
>
> On 12 April 2013 15:51, Simon Williams 
> wrote:
>
>> I use Atlassian products, but use Crowd to provide single signon. This
>> means that Crowd is the only application that needs to authenticate against
>> LDAP. I found that I had to tell Crowd that the server was 389 DS. I could
>> not get it to work set to OpenLDAP.
>>
>
>  I had a look at crowd but it seemed like overkill when I could just
> point everything at FreeIPA.
>  We are a small shop so the extra queries weren't going to affect much.
>  I tried telling my Atlaassian apps that freeipa was a 389 ds server but
> it refused to work properly.
>
>
> Not sure what that means, exactly.  Check the 389 access logs to see what
> operations Atlassian is performing against 389.
>

I don't remember the exact error and they get used every day and they work
as is so I will have to wait for an update to switch it over to see what
errors it produces.


>
>
>   Slightly strange considering the ldap modules for all of them are the
> same as the one used in crowd.
>
>
>> Regards
>>
>> Simon
>>   On 11 Apr 2013 23:36, "Peter Brown"  wrote:
>>
>>> On 12 April 2013 05:04, John Dennis  wrote:
>>>
 On 04/11/2013 02:47 PM, Bartek Moczulski wrote:

> hi,
> I've got a problem with using IPA as authentication source over LDAP.
> Generally there are two approaches to LDAP authentication:
> 1. bind using admin account and read passwords from user objects (but
> in
> ipa you cannot read passwords through ldap, right?)
> 2. "bind to authenticate" - service tries to log in to ldap with user's
> credentials. If login is successful authentication is also succesful -
> this approach does not work because you cannot login to IPA ldap using
> bare username, you need a full LDAP DN.
>

  Most applications I know of that do "bind as user" to authenticate
 also permit you to specify a format string into which the user name is
 inserted (i.e. the format string is the dn, e.g.
 "uid=%u,cn=users,cn=accounts,dc=example,dc=com") -or- they do a search to
 discover the dn. If you application does not support either approach it's
 broken IMHO.

>>>
>>> I have used this method for Confluence, Jira, Stash, Icinga and Foreman.
>>>  I will be adding more applications in the future as well.
>>>  If the application doesn't support Kerberos it's the next best thing
>>> in my opinion.
>>> I have also use it to get email lists into dovecot and postfix.
>>>
>>>  One caveat I found is you need to tell Atlassian applications that
>>> FreeIPA is a plain OpenLDAP server to get it to work.
>>>  Apart from that it works "out of the box" as they say.
>>>
>>>
>>>

 Reading passwords and/or password hashes is not supported for security
 reasons.

  Now, I've got a 3rd party application supporting both mentioned above
> appoaches and the question is - how to make it work with ipa?
>
> thanks in advance,
> Bartek.
>
>
>  ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>

 --
 John Dennis 

 Looking to carve out IT costs?
 www.redhat.com/carveoutcosts/


 ___
 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 mailing 
> listFreeipa-users@redhat.comhttps://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] User Roles and access in GUI

[Stephen Ingram]

On Mon, Apr 15, 2013 at 3:13 PM, Dmitri Pal  wrote:

>  On 04/15/2013 11:11 AM, Chandan Kumar wrote:
>
>
>  I think controlling Visibility of tabs would be the best option, if
> possible, based on Roles as mentioned by Rob. As long as other entries are
> not visible in UI, even though they have read only access with command
> line, should be enough.
>
>
> It would not be a security feature though. Just a convenience because the
> same admin would be able to bind directly to ldap and run a search. This is
> why we did not go this route. Yes we can hide panels but it would not mean
> that the user can't easily get that info. So is there really a value in
> hiding? So far we did not see any this is why we did not do it, but may be
> you have some arguments that might convince us that we are wrong. Can you
> please share these arguments with us?
>

I wasn't involved in this thread before now, however, in our case we do not
allow LDAP access (only Kerberos and WebUI) from outside firewall so there
*could* be a distinction between the two. I could also present that some
users have been confused when they login to change their personal
information and see a huge list of other users. Of course, they are
directed to their information first upon login, however, we all know that
one wrong click can always happen with some users.

Perhaps it's better to just put together a new WebUI using the Python API,
however, with the fantastic new password reset page in 3.x, I've become
lazy and let users access IPA directly.

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

Re: [Freeipa-users] User Roles and access in GUI

[Dmitri Pal]

On 04/15/2013 11:11 AM, Chandan Kumar wrote:
>
> I think controlling Visibility of tabs would be the best option, if
> possible, based on Roles as mentioned by Rob. As long as other entries
> are not visible in UI, even though they have read only access with
> command line, should be enough.
>

It would not be a security feature though. Just a convenience because
the same admin would be able to bind directly to ldap and run a search.
This is why we did not go this route. Yes we can hide panels but it
would not mean that the user can't easily get that info. So is there
really a value in hiding? So far we did not see any this is why we did
not do it, but may be you have some arguments that might convince us
that we are wrong. Can you please share these arguments with us? 

>
> On Monday, April 15, 2013, Alexander Bokovoy wrote:
>
> On Mon, 15 Apr 2013, Petr Spacek wrote:
>
> On 15.4.2013 15:39, Rob Crittenden wrote:
>
> There is no easy way to do this. We start with granting
> all authenticated
> users read access to the tree with the exception of
> certain attributes (like
> passwords).
>
> You'd have to start by removing that, then one by one
> granting read access to
> the various containers based on, well, something.
>
>
> Would it be possible to create a new role to allow current
> 'read-all access' and add this role to all users by default?
>
> It could be much simpler to change the behaviour with this
> role, or not? :-)
>
> It would affect service accounts (include host/fqdn@REALM) since roles
> cannot be applied to them, if I remember correctly. We would need to
> make an exclusive ACI that allows all services to gain read only
> access...
>
> -- 
> / Alexander Bokovoy
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
> -- 
>
> --
> http://about.me/chandank
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

[Christian Hernandez]

We are running 1.9.2

Looks like 3.0 is available for my build of CentOS ~ Any suggestions on how
to proceed to updating? Is Multimaster replication "sustained" during
updating?


Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com 
www.4over.com 


On Mon, Apr 15, 2013 at 11:29 AM, Rob Crittenden wrote:

> Christian Hernandez wrote:
>
>> Hello,
>>
>>  From time to time we are getting complaints that I can sum up as "I
>> cannot log in to server X"
>>
>> Here is a spinet of the /var/log/sssd/sssd_DOMAIN.log ...
>>
>> /(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler] (0x0100): Got request with the following data
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): command: PAM_ACCT_MGMT
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): domain: 4OVER.COM 
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): user: tradeftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): service: vsftpd
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): tty: ftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): ruser: tradeftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): rhost: mammoth.4over.com
>> 
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): authtok type: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): authtok size: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): newauthtok type: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): newauthtok size: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): priv: 1
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): cli_pid: 17841
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule
>> [allow_all]
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, )
>> [Success]
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success)
>> [Success]
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler_callback] (0x0100): Sending result [0][4OVER.COM
>> ]
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler_callback] (0x0100): Sent result [0][4OVER.COM
>> ]
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler] (0x0100): Got request with the following data
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): command: PAM_SETCRED
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): domain: 4OVER.COM 
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): user: tradeftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): service: vsftpd
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): tty: ftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): ruser: tradeftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): rhost: mammoth.4over.com
>> 
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): authtok type: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): authtok size: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): newauthtok type: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): newauthtok size: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): priv: 1
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): cli_pid: 17841
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [be_pam_h

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

[Rob Crittenden]

Christian Hernandez wrote:

Hello,

 From time to time we are getting complaints that I can sum up as "I
cannot log in to server X"

Here is a spinet of the /var/log/sssd/sssd_DOMAIN.log ...

/(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler] (0x0100): Got request with the following data
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): command: PAM_ACCT_MGMT
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): domain: 4OVER.COM 
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): user: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): service: vsftpd
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): tty: ftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): ruser: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): rhost: mammoth.4over.com

(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): authtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): authtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): newauthtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): newauthtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): priv: 1
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): cli_pid: 17841
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, )
[Success]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success)
[Success]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler_callback] (0x0100): Sending result [0][4OVER.COM
]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler_callback] (0x0100): Sent result [0][4OVER.COM
]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler] (0x0100): Got request with the following data
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): command: PAM_SETCRED
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): domain: 4OVER.COM 
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): user: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): service: vsftpd
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): tty: ftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): ruser: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): rhost: mammoth.4over.com

(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): authtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): authtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): newauthtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): newauthtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): priv: 1
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): cli_pid: 17841
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler] (0x0100): Sending result [0][4OVER.COM ]
(Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM ]]]
[be_get_account_info] (0x0100): Got request for [3][1][name=tradeftp]
(Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM ]]]
[sdap_initgr_nested_search] (0x0040): Search for group
cn=ipausers,cn=groups,cn=accounts,dc=4over,dc=com, returned 0 results.
Skipping
/

Here (more interesting) is the krb log file


/(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [unpack_buffer]
(0x0100): cmd [241] uid [6676] gid [104] validate [true] offline [false]
UPN [trade...@4over.com ]
(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [unpack_buffer]
(0x0100): ccna

[Freeipa-users] IPA not authenticating - SSSD issue maybe

[Christian Hernandez]

Hello,

>From time to time we are getting complaints that I can sum up as "I cannot
log in to server X"

Here is a spinet of the /var/log/sssd/sssd_DOMAIN.log ...

*(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler]
(0x0100): Got request with the following data
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
command: PAM_ACCT_MGMT
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
domain: 4OVER.COM
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
user: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
service: vsftpd
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
tty: ftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
ruser: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
rhost: mammoth.4over.com
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
authtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
authtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
newauthtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
newauthtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
priv: 1
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
cli_pid: 17841
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [ipa_hbac_evaluate_rules]
(0x0080): Access granted by HBAC rule [allow_all]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler_callback]
(0x0100): Backend returned: (0, 0, ) [Success]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler_callback]
(0x0100): Backend returned: (0, 0, Success) [Success]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler_callback]
(0x0100): Sending result [0][4OVER.COM]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler_callback]
(0x0100): Sent result [0][4OVER.COM]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler] (0x0100):
Got request with the following data
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
command: PAM_SETCRED
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
domain: 4OVER.COM
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
user: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
service: vsftpd
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
tty: ftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
ruser: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
rhost: mammoth.4over.com
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
authtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
authtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
newauthtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
newauthtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
priv: 1
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100):
cli_pid: 17841
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler] (0x0100):
Sending result [0][4OVER.COM]
(Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM]]] [be_get_account_info]
(0x0100): Got request for [3][1][name=tradeftp]
(Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM]]]
[sdap_initgr_nested_search] (0x0040): Search for group
cn=ipausers,cn=groups,cn=accounts,dc=4over,dc=com, returned 0 results.
Skipping
*

Here (more interesting) is the krb log file


*(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [unpack_buffer]
(0x0100): cmd [241] uid [6676] gid [104] validate [true] offline [false]
UPN [trade...@4over.com]
(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [unpack_buffer]
(0x0100): ccname: [FILE:/tmp/krb5cc_6676_0CTKUc] keytab: [/etc/krb5.keytab]
(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [krb5_child_setup]
(0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment.
(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [krb5_child_setup]
(0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment.
(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855
[krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true]
(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [krb5_child_setup]
(0x0100): Not using FAST.
(Mon Apr 15 09:36:56 2013) [[sssd[krb5_child[17862 [unpack_buffer]
(0x0100): cmd [241] uid [6676] gid [104] validate [true] offline [false]
UPN [trade...@4over.com]
(Mon Apr 15 09:36:56 2013) [[sssd[krb5_child[17862 [unpack_buffer]
(0x0100): ccname: [FILE:/tmp/krb5cc_6676_0CTKUc] keytab: [/etc/krb5.keytab]
(Mo

Re: [Freeipa-users] FreeIPA dual stacked

[Sigbjorn Lie]

On 04/15/2013 05:45 PM, Adam Bishop wrote:

Hi,

I've just had a go at deploying FreeIPA v3.1.3 and have hit a minor road bump.

   The server hostname resolves to more than one address:
 :::::4
 xxx.xxx.xxx.180
   Please provide the IP address to be used for this host name:

The answer I would like to give here is both - is this a limitation of the 
installation script that I can fix up later, or is FreeIPA incompatible with 
dual-stacked hosts at the moment?

Thanks,





My IPA was installed having dual stack from the beginning and is working 
just fine with dual stack today. That was IPA 2.1.3 when I originally 
installed it.



Regards,
Siggi

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

Re: [Freeipa-users] FreeIPA dual stacked

[John Dennis]

On 04/15/2013 11:45 AM, Adam Bishop wrote:

Hi,

I've just had a go at deploying FreeIPA v3.1.3 and have hit a minor road bump.

   The server hostname resolves to more than one address:
 :::::4
 xxx.xxx.xxx.180
   Please provide the IP address to be used for this host name:

The answer I would like to give here is both - is this a limitation of the 
installation script that I can fix up later, or is FreeIPA incompatible with 
dual-stacked hosts at the moment?


We're supposed to work fine with IPv6. Dual stack should also be fine. I 
know we've done a bunch of testing in this area but apparently something 
fell through the cracks. I suspect this is an installer only issue where 
it's validation logic is not sufficiently robust. Please open a bug 
report so we can address this. I think if you pick one of the addresses 
and let the install proceed everything should just work. Please let us 
know if it doesn't. I'm not surprised we still have some IPv6 bumps to 
smooth out, it doesn't get exercised as much as IPv4. FWIW we fully 
expect IPv6 enabled systems to be dual stack.



--
John Dennis 

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

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

Re: [Freeipa-users] FreeIPA dual stacked

[Erinn Looney-Triggs]

On 04/15/2013 09:45 AM, Adam Bishop wrote:
> Hi,
> 
> I've just had a go at deploying FreeIPA v3.1.3 and have hit a minor road bump.
> 
>   The server hostname resolves to more than one address:
> :::::4
> xxx.xxx.xxx.180
>   Please provide the IP address to be used for this host name: 
> 
> The answer I would like to give here is both - is this a limitation of the 
> installation script that I can fix up later, or is FreeIPA incompatible with 
> dual-stacked hosts at the moment? 
> 
> Thanks,
> 
> Adam Bishop
> 
>  gpg: 0x6609D460
> 
> Janet, the UK's research and education network.
> 
> 
> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
> not-for-profit company which is registered in England under No. 2881024 
> and whose Registered Office is at Lumen House, Library Avenue,
> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
> 
> 
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
> 

Probably the installer.

I have a a dual stacked IPA setup that is working just fine, though when
it was originally installed it was running only IPv4.

-Erinn



signature.asc
Description: OpenPGP digital signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] FreeIPA dual stacked

[Adam Bishop]

Hi,

I've just had a go at deploying FreeIPA v3.1.3 and have hit a minor road bump.

  The server hostname resolves to more than one address:
:::::4
xxx.xxx.xxx.180
  Please provide the IP address to be used for this host name: 

The answer I would like to give here is both - is this a limitation of the 
installation script that I can fix up later, or is FreeIPA incompatible with 
dual-stacked hosts at the moment? 

Thanks,

Adam Bishop

 gpg: 0x6609D460

Janet, the UK's research and education network.


Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238


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

[Freeipa-users] User Roles and access in GUI

[Chandan Kumar]

I think controlling Visibility of tabs would be the best option, if
possible, based on Roles as mentioned by Rob. As long as other entries are
not visible in UI, even though they have read only access with command
line, should be enough.


On Monday, April 15, 2013, Alexander Bokovoy wrote:

> On Mon, 15 Apr 2013, Petr Spacek wrote:
>
>> On 15.4.2013 15:39, Rob Crittenden wrote:
>>
>>> There is no easy way to do this. We start with granting all authenticated
>>> users read access to the tree with the exception of certain attributes
>>> (like
>>> passwords).
>>>
>>> You'd have to start by removing that, then one by one granting read
>>> access to
>>> the various containers based on, well, something.
>>>
>>
>> Would it be possible to create a new role to allow current 'read-all
>> access' and add this role to all users by default?
>>
>> It could be much simpler to change the behaviour with this role, or not?
>> :-)
>>
> It would affect service accounts (include host/fqdn@REALM) since roles
> cannot be applied to them, if I remember correctly. We would need to
> make an exclusive ACI that allows all services to gain read only access...
>
> --
> / Alexander Bokovoy
>
> __**_
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/**mailman/listinfo/freeipa-users
>


-- 

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

Re: [Freeipa-users] User Roles and access in GUI

[Alexander Bokovoy]

On Mon, 15 Apr 2013, Petr Spacek wrote:

On 15.4.2013 15:39, Rob Crittenden wrote:

There is no easy way to do this. We start with granting all authenticated
users read access to the tree with the exception of certain attributes (like
passwords).

You'd have to start by removing that, then one by one granting read access to
the various containers based on, well, something.


Would it be possible to create a new role to allow current 'read-all 
access' and add this role to all users by default?


It could be much simpler to change the behaviour with this role, or not? :-)

It would affect service accounts (include host/fqdn@REALM) since roles
cannot be applied to them, if I remember correctly. We would need to
make an exclusive ACI that allows all services to gain read only access...

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] User Roles and access in GUI

[Petr Spacek]

On 15.4.2013 15:39, Rob Crittenden wrote:

There is no easy way to do this. We start with granting all authenticated
users read access to the tree with the exception of certain attributes (like
passwords).

You'd have to start by removing that, then one by one granting read access to
the various containers based on, well, something.


Would it be possible to create a new role to allow current 'read-all access' 
and add this role to all users by default?


It could be much simpler to change the behaviour with this role, or not? :-)

--
Petr Spacek

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

Re: [Freeipa-users] ipa-server-install: ERROR Failed to initialize IPA API

[Arturo Borrero]

On 15/04/13 15:33, Martin Kosek wrote:

On 04/15/2013 03:16 PM, Arturo Borrero wrote:

Hi there,

In a freshly installed server, I try:

# ipa-server-install
[...]
   [12/13]: restarting httpd
   [13/13]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Sample zone file for bind has been created in /tmp/sample.zone.NGKJk1.db
Restarting the web server
Configuration of client side components failed!
ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master
--unattended --domain cica.es --server sheldon.cica.es --realm CICA.ES
--hostname sheldon.cica.es' returned non-zero exit status 1

If I see the ipa-client-install logs, I have:

[...]
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py'
args=klist -V
stdout=Kerberos 5 version 1.10.3

stderr=
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/role.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/service.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/user.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py'
Failed to initialize IPA API.
Installation failed. Rolling back changes.
IPA client is not configured on this system.

I fit all prerequisites listed in fedora and redhat documentation:
http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html


After this, if I try ipactl:

# ipactl start
Starting Directory Service
Starting dirsrv:
 CICA-ES... already running [  OK  ]
 PKI-IPA... already running [  OK  ]
Failed to read data from Directory Service: Unknown error when retrieving list
of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', 'desc':
'Unknown authentication method'}
Shutting down
Shutting down dirsrv:
 CICA-ES... [  OK  ]
 PKI-IPA... [  OK  ]


Any idea how to get rid of this error and continuing installing/using?

regards


Hello Arturo,

This error could have been caused if /etc/ipa/default.conf was not created
before ipa-client-install was executed.

Could you please check ipaserver-install.log and see if there are not any
errors related to creating /etc/ipa/default.conf?

Does /etc/ipa/ exist?

Thanks,
Martin

Thanks,

/etc/ipa exist, with this content:

[root@sheldon ipa]# ll -R
.:
total 8
-r--r--r--. 1 root root 1295 abr 15 13:40 ca.crt
drwxr-xr-x. 2 root root 4096 abr 12 11:37 html

./html:
total 28
-rw-r--r--. 1 root root 3929 mar  8 15:10 browserconfig.html
-rw-r--r--. 1 root root 2871 mar  8 15:10 ffconfig.js
-rw-r--r--. 1 root root 4603 mar  8 15:10 ffconfig_page.js
-rw-r--r--. 1 root root  521 mar  8 15:10 ipa_error.css
-rw-r--r--. 1 root root 3974 mar  8 15:10 ssbrowser.html
-rw-r--r--. 1 root root 1370 mar  8 15:10 unauthorized.html

So, no /etc/ipa/default.conf exist.

Which package is intended to deploy it?

regads.

--
Arturo Borrero González
Departamento de Seguridad Informática
Centro Informático Científico de Andalucía (CICA)
Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain)
Tfno.: +34 955 056 600 / FAX: +34 955 056 650
Consejería de Economía, Innovación, Ciencia y Empleo
Junta de Andalucía




smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] ipa-server-install: ERROR Failed to initialize IPA API

[Martin Kosek]

On 04/15/2013 03:50 PM, Rob Crittenden wrote:
> Arturo Borrero wrote:
>> On 15/04/13 15:33, Martin Kosek wrote:
>>> On 04/15/2013 03:16 PM, Arturo Borrero wrote:
 Hi there,

 In a freshly installed server, I try:

 # ipa-server-install
 [...]
[12/13]: restarting httpd
[13/13]: configuring httpd to start on boot
 Done configuring the web interface (httpd).
 Applying LDAP updates
 Restarting the directory server
 Restarting the KDC
 Sample zone file for bind has been created in /tmp/sample.zone.NGKJk1.db
 Restarting the web server
 Configuration of client side components failed!
 ipa-client-install returned: Command '/usr/sbin/ipa-client-install
 --on-master
 --unattended --domain cica.es --server sheldon.cica.es --realm CICA.ES
 --hostname sheldon.cica.es' returned non-zero exit status 1

 If I see the ipa-client-install logs, I have:

 [...]
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py'
 args=klist -V
 stdout=Kerberos 5 version 1.10.3

 stderr=
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py'
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py'
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py'
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py'
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py'
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py'
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py'
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py'
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py'
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py'
 importing plugin module
 '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py'
 Failed to initialize IPA API.
 Installation failed. Rolling back changes.
 IPA client is not configured on this system.

 I fit all prerequisites listed in fedora and redhat documentation:
 http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html




 After this, if I try ipactl:

 # ipactl start
 Starting Directory Service
 Starting dirsrv:
  CICA-ES... already running [  OK  ]
  PKI-IPA... already running [  OK  ]
 Failed to read data from Directory Service: Unknown error when
 retrieving list
 of services from LDAP: {'info': 'SASL(-4): no mechanism available: ',
 'desc':
 'Unknown authentication method'}
 Shutting down
 Shutting down dirsrv:
  CICA-ES... [  OK  ]
  PKI-IPA... [  OK  ]


 Any idea how to get rid of this error and continuing installing/using?

 regards

>>> Hello Arturo,
>>>
>>> This error could have been caused if /etc/ipa/default.conf was not
>>> created
>>> before ipa-client-install was executed.
>>>
>>> Could you please check ipaserver-install.log and see if there are not any
>>> errors related to creating /etc/ipa/default.conf?
>>>
>>> Does /etc/ipa/ exist?
>>>
>>> Thanks,
>>> Martin
>> Thanks,
>>
>> /etc/ipa exist, with this content:
>>
>> [root@sheldon ipa]# ll -R
>> .:
>> total 8
>> -r--r--r--. 1 root root 1295 abr 15 13:40 ca.crt
>> drwxr-xr-x. 2 root root 4096 abr 12 11:37 html
>>
>> ./html:
>> total 28
>> -rw-r--r--. 1 root root 3929 mar  8 15:10 browserconfig.html
>> -rw-r--r--. 1 root root 2871 mar  8 15:10 ffconfig.js
>> -rw-r--r--. 1 root root 4603 mar  8 15:10 ffconfig_page.js
>> -rw-r--r--. 1 root root  521 mar  8 15:10 ipa_error.css
>> -rw-r--r--. 1 root root 3974 mar  8 15:10 ssbrowser.html
>> -rw-r--r--. 1 root root 1370 mar  8 15:10 unauthorized.html
>>
>> So, no /etc/ipa/default.conf exist.
>>
>> Which package is intended to deploy it?
> 
> The server installer creates it.
> 
> I believe this file gets removed by the client when its install fails.
> 
> The server log may have some failures though, as suggested by Martin, so I'd
> start there.
> 
> rob

This file is being created right after the wizard part of ipa-server-install,
so when the services are being configured, it should be there (you can check
that and get its contents). Unfortunately, there is not logging around it, so
you may not see much info in you ipaserver-install.log...

BTW I really suspect that missing or unreadable /etc/ipa/default.conf may
really be the root cause of this issue, I reproduced this exact message when I
run "ipa-client-install --on-

Re: [Freeipa-users] ipa-server-install: ERROR Failed to initialize IPA API

[Rob Crittenden]

Arturo Borrero wrote:

On 15/04/13 15:33, Martin Kosek wrote:

On 04/15/2013 03:16 PM, Arturo Borrero wrote:

Hi there,

In a freshly installed server, I try:

# ipa-server-install
[...]
   [12/13]: restarting httpd
   [13/13]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Sample zone file for bind has been created in /tmp/sample.zone.NGKJk1.db
Restarting the web server
Configuration of client side components failed!
ipa-client-install returned: Command '/usr/sbin/ipa-client-install
--on-master
--unattended --domain cica.es --server sheldon.cica.es --realm CICA.ES
--hostname sheldon.cica.es' returned non-zero exit status 1

If I see the ipa-client-install logs, I have:

[...]
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py'
args=klist -V
stdout=Kerberos 5 version 1.10.3

stderr=
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/role.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/service.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/user.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py'
Failed to initialize IPA API.
Installation failed. Rolling back changes.
IPA client is not configured on this system.

I fit all prerequisites listed in fedora and redhat documentation:
http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html



After this, if I try ipactl:

# ipactl start
Starting Directory Service
Starting dirsrv:
 CICA-ES... already running [  OK  ]
 PKI-IPA... already running [  OK  ]
Failed to read data from Directory Service: Unknown error when
retrieving list
of services from LDAP: {'info': 'SASL(-4): no mechanism available: ',
'desc':
'Unknown authentication method'}
Shutting down
Shutting down dirsrv:
 CICA-ES... [  OK  ]
 PKI-IPA... [  OK  ]


Any idea how to get rid of this error and continuing installing/using?

regards


Hello Arturo,

This error could have been caused if /etc/ipa/default.conf was not
created
before ipa-client-install was executed.

Could you please check ipaserver-install.log and see if there are not any
errors related to creating /etc/ipa/default.conf?

Does /etc/ipa/ exist?

Thanks,
Martin

Thanks,

/etc/ipa exist, with this content:

[root@sheldon ipa]# ll -R
.:
total 8
-r--r--r--. 1 root root 1295 abr 15 13:40 ca.crt
drwxr-xr-x. 2 root root 4096 abr 12 11:37 html

./html:
total 28
-rw-r--r--. 1 root root 3929 mar  8 15:10 browserconfig.html
-rw-r--r--. 1 root root 2871 mar  8 15:10 ffconfig.js
-rw-r--r--. 1 root root 4603 mar  8 15:10 ffconfig_page.js
-rw-r--r--. 1 root root  521 mar  8 15:10 ipa_error.css
-rw-r--r--. 1 root root 3974 mar  8 15:10 ssbrowser.html
-rw-r--r--. 1 root root 1370 mar  8 15:10 unauthorized.html

So, no /etc/ipa/default.conf exist.

Which package is intended to deploy it?


The server installer creates it.

I believe this file gets removed by the client when its install fails.

The server log may have some failures though, as suggested by Martin, so 
I'd start there.


rob

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

Re: [Freeipa-users] User Roles and access in GUI

[Rob Crittenden]

Dmitri Pal wrote:

On 04/12/2013 08:17 PM, Chandan Kumar wrote:


Thanks for the response.

The way we can turn off the anonymous bind in 389 Server. using
 "nsslapd-allow-anonymous-access: off".

Is there any way to limit the read access of user to only to the DNS
entries? In that way I can create a user who could/will be able to
see/edit DNS entries only.


In general yes though it is not standard because as I mentioned earlier
the tree is assumed to be readable to an authenticated user.
When user logs in the framework the UI or CLI will log into LDAP as a
user and try to do operations. It will need to read user entry and
groups and other things so closing read access to everything other than
DNS would not work. You can close access to some of the objects but not
to all of them.
It still unclear what is the harm in ability to read other parts of the
tree but not modify them.

To change the permissions you would have to user LDAP level ACI commands
as we do not expose these capabilities via CLI or UI but be careful as I
mentioned above you might end up hiding something that would prevent
framework from functioning properly.


There is no easy way to do this. We start with granting all 
authenticated users read access to the tree with the exception of 
certain attributes (like passwords).


You'd have to start by removing that, then one by one granting read 
access to the various containers based on, well, something.


It would be very prone to error, with probably lots of corner cases and 
overlap.


Do you really want to deny read access or do you want to simplify the 
the UI to include only certain tabs/functions?


rob

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

Re: [Freeipa-users] ipa-server-install: ERROR Failed to initialize IPA API

[Martin Kosek]

On 04/15/2013 03:16 PM, Arturo Borrero wrote:
> Hi there,
> 
> In a freshly installed server, I try:
> 
> # ipa-server-install
> [...]
>   [12/13]: restarting httpd
>   [13/13]: configuring httpd to start on boot
> Done configuring the web interface (httpd).
> Applying LDAP updates
> Restarting the directory server
> Restarting the KDC
> Sample zone file for bind has been created in /tmp/sample.zone.NGKJk1.db
> Restarting the web server
> Configuration of client side components failed!
> ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master
> --unattended --domain cica.es --server sheldon.cica.es --realm CICA.ES
> --hostname sheldon.cica.es' returned non-zero exit status 1
> 
> If I see the ipa-client-install logs, I have:
> 
> [...]
> importing plugin module
> '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py'
> args=klist -V
> stdout=Kerberos 5 version 1.10.3
> 
> stderr=
> importing plugin module 
> '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py'
> importing plugin module
> '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py'
> importing plugin module
> '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py'
> importing plugin module
> '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py'
> importing plugin module
> '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py'
> importing plugin module
> '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py'
> importing plugin module
> '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py'
> importing plugin module 
> '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py'
> importing plugin module 
> '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py'
> importing plugin module
> '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py'
> importing plugin module
> '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py'
> Failed to initialize IPA API.
> Installation failed. Rolling back changes.
> IPA client is not configured on this system.
> 
> I fit all prerequisites listed in fedora and redhat documentation:
> http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html
> 
> 
> After this, if I try ipactl:
> 
> # ipactl start
> Starting Directory Service
> Starting dirsrv:
> CICA-ES... already running [  OK  ]
> PKI-IPA... already running [  OK  ]
> Failed to read data from Directory Service: Unknown error when retrieving list
> of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', 'desc':
> 'Unknown authentication method'}
> Shutting down
> Shutting down dirsrv:
> CICA-ES... [  OK  ]
> PKI-IPA... [  OK  ]
> 
> 
> Any idea how to get rid of this error and continuing installing/using?
> 
> regards
> 

Hello Arturo,

This error could have been caused if /etc/ipa/default.conf was not created
before ipa-client-install was executed.

Could you please check ipaserver-install.log and see if there are not any
errors related to creating /etc/ipa/default.conf?

Does /etc/ipa/ exist?

Thanks,
Martin

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

Re: [Freeipa-users] User Roles and access in GUI

[Dmitri Pal]

On 04/12/2013 08:17 PM, Chandan Kumar wrote:
>
> Thanks for the response.
>
> The way we can turn off the anonymous bind in 389 Server. using
>  "nsslapd-allow-anonymous-access: off".
>
> Is there any way to limit the read access of user to only to the DNS
> entries? In that way I can create a user who could/will be able to
> see/edit DNS entries only.

In general yes though it is not standard because as I mentioned earlier
the tree is assumed to be readable to an authenticated user.
When user logs in the framework the UI or CLI will log into LDAP as a
user and try to do operations. It will need to read user entry and
groups and other things so closing read access to everything other than
DNS would not work. You can close access to some of the objects but not
to all of them.
It still unclear what is the harm in ability to read other parts of the
tree but not modify them.

To change the permissions you would have to user LDAP level ACI commands
as we do not expose these capabilities via CLI or UI but be careful as I
mentioned above you might end up hiding something that would prevent
framework from functioning properly.

>
> Thanks,
> Chandan
>
> On Friday, April 12, 2013, Dmitri Pal wrote:
>
> On 04/12/2013 02:23 AM, Martin Kosek wrote:
> > On 04/12/2013 01:07 AM, Chandan Kumar wrote:
> >> Hello,
> >>
> >> I have a question regarding Uer Roles and Access in GUI. What I
> have found that
> >> irrespective of Role assigned to a user, he gets read only
> access across the
> >> directory.
> >>
> >> For example, I created one user say "dnsadmin" with only Roles
> related to DNS
> >> such as DNS Servers, DNS Administrator. Now that user has read
> only access to
> >> entire directory. Is there any way of controlling it?
> >>
> >>
> >> Thanks,
> >> Chandan
> >>
> > Hello Chandan,
> >
> > If you create a new role, assign "DNS Administrators" privilege
> to it, and
> > assign that role to user dnsadmin, that user will have write
> access to DNS tree
> > and configuration.
> >
> > Beyond that tree, dnsadmin will have read-only access just like
> all other
> > non-admin users. If you want dnsadmin to have write access also
> to other
> > entries, you would need to assign more privileges/roles to it.
> >
> > HTH,
> > Martin
> >
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com 
> > https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
> If you are worried about the read access the LDAP data is
> traditionally
> readable by any authenticated user.
> In the past is was even possible to read the tree as anonymous user
> which is a bad security practice and not recommended.
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> ---
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/ 
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com 
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
> -- 
>
> --
> http://about.me/chandank
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

[Freeipa-users] ipa-server-install: ERROR Failed to initialize IPA API

[Arturo Borrero]

Hi there,

In a freshly installed server, I try:

# ipa-server-install
[...]
  [12/13]: restarting httpd
  [13/13]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Sample zone file for bind has been created in /tmp/sample.zone.NGKJk1.db
Restarting the web server
Configuration of client side components failed!
ipa-client-install returned: Command '/usr/sbin/ipa-client-install 
--on-master --unattended --domain cica.es --server sheldon.cica.es 
--realm CICA.ES --hostname sheldon.cica.es' returned non-zero exit status 1


If I see the ipa-client-install logs, I have:

[...]
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py'

args=klist -V
stdout=Kerberos 5 version 1.10.3

stderr=
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/role.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/service.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/user.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py'
importing plugin module 
'/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py'

Failed to initialize IPA API.
Installation failed. Rolling back changes.
IPA client is not configured on this system.

I fit all prerequisites listed in fedora and redhat documentation:
http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html

After this, if I try ipactl:

# ipactl start
Starting Directory Service
Starting dirsrv:
CICA-ES... already running [  OK  ]
PKI-IPA... already running [  OK  ]
Failed to read data from Directory Service: Unknown error when 
retrieving list of services from LDAP: {'info': 'SASL(-4): no mechanism 
available: ', 'desc': 'Unknown authentication method'}

Shutting down
Shutting down dirsrv:
CICA-ES... [  OK  ]
PKI-IPA... [  OK  ]


Any idea how to get rid of this error and continuing installing/using?

regards

--
Arturo Borrero González
Departamento de Seguridad Informática
Centro Informático Científico de Andalucía (CICA)
Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain)
Tfno.: +34 955 056 600 / FAX: +34 955 056 650
Consejería de Economía, Innovación, Ciencia y Empleo
Junta de Andalucía




smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] sudo made a bit easier to configure

[Jakub Hrozek]

On Sun, Apr 14, 2013 at 01:49:14PM +0200, Jan-Frode Myklebust wrote:
> On Thu, Dec 20, 2012 at 04:43:08PM +0100, Han Boetes wrote:
> An even better config would be if we could use the host's keytab to bind
> to LDAP here..

Coming up as a default in sssd 1.10 (beta).

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