[SSSD] RADIUS provider

Dmitri Pal dpal at redhat.com
Wed May 1 15:28:05 UTC 2013


On 04/30/2013 06:42 PM, Ondra Hujňák wrote:
> 30. 4. 2013 v 16:38, Dmitri Pal <dpal at redhat.com>:
>
>> On 04/30/2013 07:43 AM, Jakub Hrozek wrote:
>>> On Tue, Apr 23, 2013 at 03:44:20PM +0200, Ondra Hujňák wrote:
>>>> Hi,
>>>>
>>>> I added RADIUS client part to rad provider. It communicates with
>>>> server now and gets response (Access-Accept or Access-Reject).
>>>>
>>>> All changes are available in rad branch of my github repository:
>>>> https://github.com/hujon/sssd.git
>>>>
>>>> I used completely new krad library from Kerberos, so it depends
>>>> on krb5-libs and verto now. Because in f19 updates there is old
>>>> version with different API you need to install packages from koji:
>>>>
>>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=410384
>>>>
>>>> However when I get response, callback is correctly called,
>>>> I call be_req_terminate but the result doesn't reach su, so it
>>>> just timeouts and denies access every time. 
>>>> This is a part of my log:
>>>>
>>>> [be_pam_handler] (0x0100): Got request with the following data
>>>> [pam_print_data] (0x0100): command: PAM_AUTHENTICATE
>>>> [pam_print_data] (0x0100): domain: RAD
>>>> [pam_print_data] (0x0100): user: test
>>>> [sssd[be[RAD]]] [pam_print_data] (0x0100): service: su
>>>> [sssd[be[RAD]]] [pam_print_data] (0x0100): tty: pts/0
>>>> [sssd[be[RAD]]] [pam_print_data] (0x0100): ruser: ondra
>>>> [sssd[be[RAD]]] [pam_print_data] (0x0100): rhost:
>>>> [sssd[be[RAD]]] [pam_print_data] (0x0100): authtok type: 1
>>>> [sssd[be[RAD]]] [pam_print_data] (0x0100): newauthtok type: 0
>>>> [sssd[be[RAD]]] [pam_print_data] (0x0100): priv: 0
>>>> [sssd[be[RAD]]] [pam_print_data] (0x0100): cli_pid: 14218
>>>> [sssd[be[RAD]]] [rad_auth_send] (0x0400): Sending request
>>>> [sssd[be[RAD]]] [rad_auth_done] (0x0400): Permission granted for user test.
>>>> [sssd[be[RAD]]] [rad_auth_done] (0x0400): Callback terminating be_req.
>>>> [sssd[be[RAD]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, <NULL>) [Success]
>>>> [sssd[be[RAD]]] [be_pam_handler_callback] (0x0100): Sending result [0][RAD]
>>>> [sssd[be[RAD]]] [be_pam_handler_callback] (0x0100): Sent result [0][RAD]
>>>> [sssd[be[RAD]]] [rad_auth_done] (0x0400): Callback freeing req.
>>>>
>>>> If you have any idea what's wrong or any other comments about
>>>> my code I'll be glad to know ;)
>>>>
>>>> Ondrej
>>> According to the log, the backend sent the return code back to the
>>> sssd_pam frontend. If you put debug_level=10 into the [pam] section, do
>>> you see anything logged there?
> Well, tons of messages, but this part seems interesting:
>
> [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'test' matched without domain, user is test
> [sssd[pam]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)]
> [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE
> [sssd[pam]] [pam_print_data] (0x0100): domain: not set
> [sssd[pam]] [pam_print_data] (0x0100): user: test
> [sssd[pam]] [pam_print_data] (0x0100): service: su
> [sssd[pam]] [pam_print_data] (0x0100): tty: pts/0
> [sssd[pam]] [pam_print_data] (0x0100): ruser: ondra
> [sssd[pam]] [pam_print_data] (0x0100): rhost: not set
> [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1
> [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0
> [sssd[pam]] [pam_print_data] (0x0100): priv: 0
> [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 19548
> [sssd[pam]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/RAD/test]
> [sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x4168c0:3:test at RAD]
> [sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [RAD][3][1][name=test]
> [sssd[pam]] [sbus_add_timeout] (0x2000): 0xd479c0
> [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x4168c0:3:test at RAD]
> [sssd[pam]] [sbus_remove_timeout] (0x2000): 0xd479c0
> [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: D478B0
> [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching.
> [sssd[pam]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success
> [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [test at RAD]
>
> But it still seems ok to me, I have no idea why su does not respond and waits till timeout.
>
>>> Other comments about the code:
>>> * You can use the standard HOST_NAME_MAX instead of HOSTNAME_LEN_MAX
> I did not know about that, it's changed now.
>
>>> * Please don't use space after opening "("
> I try to avoid this, but it seems I forgot about function definitions. It should be fixed by now.
>
>>> * rad_req_free() should be a talloc destructor. See how we use
>>>   talloc_set_destructor elsewhere. Then because rad_req is allocated on
>>>   top of be_req, you won't have to free it explicitly at all, it's
>>>   going to be freed when be_req goes away.
> Well, I have to explicitly free stuff allocated by verto and krad libraries, because they are probably malloc'd,
> but putting it into talloc destruktor is good idea. 
>
> I have moved it to destructor and it gets called, but somehow it causes problems when stopping SSSD.
> systemctl stop sssd just hangs and then fails.
>
>>> * I think there should be a utility function that would reduce code
>>>   duplication of this block:
>>>    tmp = string2data(pass);
>>>    kerr = krad_attrset_add(rad_req->attrs,
>>>                            krad_attr_name2num("User-Password"),
>>>                            &tmp);
>>>    free(tmp.data);
> You're right, I moved it to add_str_attr function and the code looks much better now.
>
>>> * And most importanly: I don't really like libverto requests mixed with
>>>   tevent requests in the code. At the very least, the libverto
>>>   krad_client_send request should be wrapped in a tevent request. The
>>>   main rad_auth.c module would call:
>>>
>>>   subreq = sss_rad_auth_send(parameters);
>>>   if (subreq == NULL) {
>>>        /* error */
>>>   }
>>>   tevent_req_callback(subreq, rad_auth_done, rad_req);
>>>
>>>   Then sss_rad_auth_send should do the libverto stuff internally. To be
>>>   honest, I'm not sure how safe it is to combine libverto and libtevent
>>>   in a single process, we should check with tevent/libverto experts,
>>>   maybe it would be safer to move the authentication into a separate
>>>   process that would use libretto
> I thought about moving it to sub request myself, but decided that it isn't worth it :)
> I'll move it into subrequest in my next commit.
>
> I had no idea that combining libverto and libtevent could do any harm,
> could you suggest someone who could tell?
>
> Maybe those problems with pam request timeouts and sssd stop failures are
> caused by this. I'll probably try to move it to new process...

Libverto is a wrapper around different event loops it should work with
libtevent without any issues. If it does not it is a bug.
If you need more info on libvierto Nathaniel McCallum is your man. Try
to reach him on #freeipa if you have any questions.

>>> Also is there any howto on setting the environment? I admit I have never
>>> used radius, so I'm really at loss on how to configure it.
>> I guess you setup a freeradius server following the HOWTOs on its wiki.
>> The trick is to establish a shared secret.
>> There are several open source radius test clients. You can try those and
>> see how they work.
>>
>> If you have any questions do not hesitate to ask.
>>
> I have pretty good howto in text of my thesis, I have attached it, but
> apart from information about how to set up the environment it's highly 
> unfinished and experimental text ;)
>
>>> _______________________________________________
>>> sssd-devel mailing list
>>> sssd-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>
>> -- 
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager for IdM portfolio
>> Red Hat Inc.
>>
>>
>> -------------------------------
>> Looking to carve out IT costs?
>> www.redhat.com/carveoutcosts/
>>
>>
>>
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> Ondřej Hujňák
>
>
>
>
>
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20130501/ce1142cc/attachment.html>


More information about the sssd-devel mailing list