[PATCH] AD: Always use TokenGroups
by Ondrej Kos
Hi,
Attached patch applies on top of Sumit's patchset and addresses bug
https://fedorahosted.org/sssd/ticket/1568
When SID is always stored, we are able to use tokengroups in AD even
with ID mapping option disabled.
Please, could some native speaker check the manpage change for correct
wording?
Ondra
--
Ondrej Kos
Associate Software Engineer
Identity Management
Red Hat Czech
10 years, 11 months
RADIUS provider
by 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
10 years, 12 months
[PATCH] Fix segmentation fault in test_io.
by Lukas Slebodnik
I wanted to revie som patches, but test failed with unrelated issue to revieved
patch.
------------------------------------------
[ RUN ] test_sss_open_cloexec_success
mkstemp failed
fd != -1
ERROR: ../sssd/src/tests/cmocka/test_io.c:81 Failure!
[ FAILED ] test_sss_open_cloexec_success
[ RUN ] test_sss_open_cloexec_fail
[ OK ] test_sss_open_cloexec_fail
[ RUN ] test_sss_openat_cloexec_success
mkstemp failed
11
[ FAILED ] test_sss_openat_cloexec_success
[ RUN ] test_sss_openat_cloexec_fail
/bin/sh: line 5: 12545 Segmentation fault (core dumped) LDB_MODULES_PATH=/dev/shm/sssd_build/ldb_mod_test_dir ${dir}$tst
FAIL: test-io
------------------------------------------
Attached patch fix this bug.
LS
10 years, 12 months
[PATCH] Display the last grace warning, too
by Jakub Hrozek
The attached patch fixes displaying of the last grace password warning,
iow when grace == 0. I checked that this is what pam_ldap does, too.
The patch has been tested by a GSS engineer.
10 years, 12 months
RFC: dropping upstream support of RHEL5 starting with 1.10
by Jakub Hrozek
Hi,
many new features rely on library APIs and features that are only available
in recent versions of SSSD dependencies. As a result, the code often needs
#ifdefs and special branches in order to at least compile or run on RHEL5.
So far we've been doing nightly builds also for RHEL5 and fixing issues
as we were finding them. But recently we are considering dropping support
for RHEL5 -- it is causing some engineering effort and at the same time
the audience is probably very limited. If you are running super-stable
enterprise distribution, chances are you are not all that interested in
the latest and possibly very unstable SSSD version.
The proposal would be to keep building and supporting the 1.9.x branch
for RHEL5 and switch to using RHEL6 as the oldest supported release
starting from the 1.10 upstream version. Of course we would still accept
patches from any potential contributors.
Any objections against the plan?
10 years, 12 months
