RADIUS provider

[Ondra Hujňák]

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

[Jakub Hrozek]

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?

Other comments about the code:
 * You can use the standard HOST_NAME_MAX instead of HOSTNAME_LEN_MAX

* Please don't use space after opening "("

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

* 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);

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

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.

[Dmitri Pal]

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?
>
> Other comments about the code:
>
> You can use the standard HOST_NAME_MAX instead of HOSTNAME_LEN_MAX
>
> Please don't use space after opening "("
>
> 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.
>
> 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);
>
> 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 libverto.
>
> 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.
> sssd-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Ondra Hujňák]

30. 4. 2013 v 16:38, Dmitri Pal :
> 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@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@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@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...
> > 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
> > [e-mail]
> > 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
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

Ondřej Hujňák

[Dmitri Pal]

On 04/30/2013 06:42 PM, Ondra Hujňák wrote:
> 2013 v 16:38, Dmitri Pal :
> > 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@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@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@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
> > > [e-mail]
> > > 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
> > [e-mail]
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>
> Ondřej Hujňák
>
> sssd-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Dmitri Pal]

On 04/30/2013 06:42 PM, Ondra Hujňák wrote:
> 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 ;)

I want to draw the attention that the introduction gives a hint on what
you are trying to do but does not cover all the use cases.

There are two reasons why people might want to use RADIUS as a part of SSSD.
1) One is to use 2FA. People might have a deployment that supports OTP
tokens. Instead of deploying special agent to the client systems that
would be able to configure SSSD with RADIUS. In this use case the
architecture looks like on the attached diagram. In this case all the
components of the solution are behind the firewall.
2) An appliance or special device. This special device has some local
accounts pre configured on the box in the passwd file or in SSSD. The
authentication should happen against the  account directory but has to
be done using RADIUS because exposing LDAP outside the firewall is a
security risk. In this case the authentication would happen via RADIUS
but then all the users should be mapped to a specific local account. In
general would be nice to allow some pattern matching.  Something like:
for each defined pattern:
 If authenticated user account matches the pattern use the local account
associated with the pattern
end

In config file it can be represented by something like (I am not sure
this is the best approach, you need to think of a better one may be):

radius_remapping = admin=root, *=guest

This would mean that if the authenticated user's name is admin he should
be remapped to the local user 'root' and his session should be as 'root'.
For all other the session should be as 'guest'.
This is just an example. I suspect that in reality 'root" would not be
used but there will be a special account created as I mentioned above.

The second use case is actually more important than the first one but I
do not see anything about use cases in your writeup yet and I suspect
that you were focusing on the use case 1). This is fine but use case 2)
is really what we are looking for.

Let me know if you have any questions.

[Ondra Hujňák]

I'm really sorry, I have forgotten to write you before.

I got you last time and I will try to add functionality for the second use case
later. Right now I'm doing my best to make at least first use case work ;)

The thing is, that this work is part of my bachelor thesis and only
first case is described in the specification of my work. Because my deadline
is 5/15 and as you could see my thesis is highly unfinished I will
cover only first use case in my thesis and I will try to add functionality
for second one later in my free time.

Thank you for attached diagrams,
Ondřej Hujňák

1. 5. 2013 v 17:55, Dmitri Pal :
> On 04/30/2013 06:42 PM, Ondra Hujňák wrote:
> > 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 ;)
>
> I want to draw the attention that the introduction gives a hint on what
> you are trying to do but does not cover all the use cases.
>
> There are two reasons why people might want to use RADIUS as a part of SSSD.
> One is to use 2FA. People might have a deployment that supports OTP
>
> tokens. Instead of deploying special agent to the client systems that
> would be able to configure SSSD with RADIUS. In this use case the
> architecture looks like on the attached diagram. In this case all the
> components of the solution are behind the firewall.
> 2) An appliance or special device. This special device has some local
> accounts pre configured on the box in the passwd file or in SSSD. The
> authentication should happen against the  account directory but has to
> be done using RADIUS because exposing LDAP outside the firewall is a
> security risk. In this case the authentication would happen via RADIUS
> but then all the users should be mapped to a specific local account. In
> general would be nice to allow some pattern matching.  Something like:
> for each defined pattern:
> If authenticated user account matches the pattern use the local account
> associated with the pattern
> end
>
> In config file it can be represented by something like (I am not sure
> this is the best approach, you need to think of a better one may be):
>
> radius_remapping = admin=root, *=guest
>
> This would mean that if the authenticated user's name is admin he should
> be remapped to the local user 'root' and his session should be as 'root'.
> For all other the session should be as 'guest'.
> This is just an example. I suspect that in reality 'root" would not be
> used but there will be a special account created as I mentioned above.
>
> The second use case is actually more important than the first one but I
> do not see anything about use cases in your writeup yet and I suspect
> that you were focusing on the use case 1). This is fine but use case 2)
> is really what we are looking for.
>
> Let me know if you have any questions.
>
> -- 
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
> <RADIUS.odg><RADIUS2.odg>_______________________________________________
> sssd-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Jakub Hrozek]

On Wed, May 01, 2013 at 12:42:47AM +0200, Ondra Hujňák wrote:
> 2013 v 16:38, Dmitri Pal :
> > 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@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@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@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@RAD" succeed?

Feel free to paste or attach the complete sssd_pam log.
> > > 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?
> > > 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?

Nathaniel or Simo, you can catch them on the #sssd or #freeipa channels.
> 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.

[Ondra Hujňák]

1. 5. 2013 v 21:16, Jakub Hrozek :
> On Wed, May 01, 2013 at 12:42:47AM +0200, Ondra Hujňák wrote:
> > 2013 v 16:38, Dmitri Pal :
> > > 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@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@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@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@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
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Jakub Hrozek]

On Thu, May 02, 2013 at 01:49:03AM +0200, Ondra Hujňák wrote:
> 2013 v 21:16, Jakub Hrozek :
> > On Wed, May 01, 2013 at 12:42:47AM +0200, Ondra Hujňák wrote:
> > > 2013 v 16:38, Dmitri Pal :
> > > > 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@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@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@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@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...

FWIW, Ondra came to the office today and we ran a debugging session
where we pinpointed the problem to a sssd_be crash during subsequent
requests. Because sssd_be was restarted, it was not easy for Ondra to
see the problem at first.

We also fixed a couple of tevent-style issues, looks like when the
crash is resolved, the patches would be complete as far as Ondra's
thesis description goes. We'd still need man pages and some final
touches, but the functionality seems to be there.