On 10/10/2013 08:33 PM, Nathaniel McCallum wrote:
> On Thu, 2013-10-10 at 15:53 -0400, Dmitri Pal wrote:
>> On 10/10/2013 03:13 PM, Nathaniel McCallum wrote:
>>> On Thu, 2013-10-10 at 12:44 -0400, Dmitri Pal wrote:
>>>> On 10/10/2013 10:51 AM, Nathaniel McCallum wrote:
>>>>> On Thu, 2013-10-10 at 10:04 +0200, Jan Cholasta wrote:
>>>>>> On 12.9.2013 22:47, Nathaniel McCallum wrote:
>>>>>>> On Thu, 2013-09-05 at 00:04 -0400, Nathaniel McCallum wrote:
>>>>>>>> patch attached
>>>>>>> Update for ./makeapi attached.
>>>>>>>
>>>>>> Is ipaUserAuthType relevant only to Kerberos or to user authentication 
>>>>>> in general? For example, if "password" is removed from ipaUserAuthType 
>>>>>> of an user, will I be able to authenticate as that user with LDAP simple 
>>>>>> authentication?
>>>>> If only "otp" is set, yes via password+otp.
>>>>>
>>>>> If only "radius" is set, this behavior is currently undefined. We should
>>>>> probably define it.
>>>> If RADIUS is used you always rely on the external system to provide
>>>> authentication for this user.
>>>> Is this the definition you are looking for?
>>> For Kerberos, yes. For LDAP, no. For LDAP, if "radius" is present,
>>> single factor authentication should probably be permitted.
>>>
>>> Nathaniel
>>>
>> Why you think they should be inconsistent?
>> If you want to have this case covered I think we need a separate type
>> something like "kerberos_radius" which will work only in kerberos but
>> not in LDAP.
>> But IMO such mode will create a lot of confusion.
>> We can also do "kerberos_radius_ldap_pwd_and_radius" that would allow
>> radius for kerberos and allow local LDAP password or RADIUS for bind but
>> I do not see a reason for this case.
>> Can you explain?
> We implemented RADIUS forwarding in the companion daemon. So the
> implementation of the ipaUserAuthType for "radius" is occurring outside
> 389ds. Hence, when ipaUserAuthType says "radius" the companion daemon
> will forward Kerberos OTP requests to RADIUS. 389ds binds, however, will
> use standard password authentication in this case. There is no way
> around this without merging RADIUS proxying into 389ds directly.


Ah right, I forget that only OTP is implemented in DS so it can be used
by bind and Kerberos.
Then we need to document expectation about "radius".

> Nathaniel
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to