[SSSD] RADIUS provider

Ondra Hujňák xhujna00 at stud.fit.vutbr.cz
Wed May 1 23:49:03 UTC 2013


1. 5. 2013 v 21:16, Jakub Hrozek <jhrozek at redhat.com>:

> On Wed, May 01, 2013 at 12:42:47AM +0200, 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.
> 
> Is that all there is in the log? Where does the user test come from?
> Does "getent passwd test at RAD" succeed?
> 
> Feel free to paste or attach the complete sssd_pam log.

After moving rad_auth_send into new subrequest it seems to work again, but I have to examine it deeper.
I have attached sssd_pam.log and sssd_RAD.log (RAD is my testing domain with RADIUS auth_provider).

Right now first request is correctly handled, but next requests get stuck in krad library. I guess I have
misused verto somehow.

User test is my testing user account stored in LDAP. I use it to test RADIUS provider.

>>>> * 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.
>> 
> 
> Does it fail after this single change?

It did, but it seems to be fixed by new subrequest as well.

>>>> * 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.

Done. Quick check if I am using tevent correctly would be great, if someone could check it.

>> I had no idea that combining libverto and libtevent could do any harm,
>> could you suggest someone who could tell?
>> 
> 
> Nathaniel or Simo, you can catch them on the #sssd or #freeipa channels.

Ok, thanks. I will try to speak to them. I'm experiencing some difficulties with
libverto, so hopefully they'll know what to do.

>> 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...
>> 
> 
> Unlikely, the sssd_pam and sssd_be are already separate processes and
> they communicate using the DBus protocol. 
> 
> My concern was about two event loops being used at the same time in a
> single process. I know that SSSD used to do it, but it was causing
> problems. I don't remember the details, sorry, maybe the problems were
> resolved in newer tevent releases.
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd_pam.log
Type: application/octet-stream
Size: 198420 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20130502/e2a6ed49/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd_RAD.log
Type: application/octet-stream
Size: 58987 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20130502/e2a6ed49/attachment-0001.obj>
-------------- next part --------------



More information about the sssd-devel mailing list