I was reprodicing other bug and it took me some time to find out why I was not
able to resolve user. RID was bigger than range size.
I saw just general message about id mapping failer
[sdap_save_user] (0x0400): Processing user matthewbe
[sdap_save_user] (0x1000): Mapping user [matthewbe] objectSID
[S-1-5-21-2997650941-1802118864-3094776726-200065] to unix ID
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
[S-1-5-21-2997650941-1802118864-3094776726-200065] to a UNIX ID
Default range size is 200000
[sdap_save_user] (0x0020): Failed to save user [matthewbe]
[sdap_save_users] (0x0040): Failed to store user 0. Ignoring.
Feel free to propose better debug message. I think it would simplify debugging.
Hi guys, I spent some time working at this ticket
https://fedorahosted.org/sssd/ticket/1108 and I think it's finally
ready to be reviewed by others.
Description of the problem and scope of the changes can be found in
the commit message. I also wrote some unit tests but the patch is a
quite long already so I think it would be better to send the tests as
an another patch. Or should I create a patch for each modified file?
Package sssd_184.108.40.206-1 on Debian FTBFS for mips and mipsel.
dyndns_test_ok is failing with following log:
[ RUN ] dyndns_test_ok(Tue Jul 8 15:53:55:004476 2014) [sssd] [be_nsupdate_args] (0x0200): (Tue Jul 8 15:53:55:004521 2014) [sssd] [child_handler_setup] (0x2000): nsupdate auth type: GSS-TSIGSetting up signal handler up for pid (Tue Jul 8 15:53:55:004693 2014) [sssd] [__wrap_execv] (0x0200): nsupdate success test case(Tue Jul 8 15:53:55:004825 2014) [sssd] [__wrap_execv] (0x1000): Child exiting with status 0(Tue Jul 8 15:53:55:005275 2014) [sssd] [child_handler_setup] (0x2000): Signal handler set up for pid (Tue Jul 8 15:54:55:837623 2014) [sssd] [write_pipe_handler] (0x0020): write failed [Broken pipe].(Tue Jul 8 15:54:55:837801 2014) [sssd] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete(Tue Jul 8 15:54:55:837869 2014) [sssd] [nsupdate_child_stdin_done] (0x0040): Sending nsupdate data failed : Broken pipe(Tue Jul 8 15:54:55:837947 2014) [sssd] [be_nsupdate_done] (0x0040): nsupdate child execution failed : Dynamic DNS update failed(Tue Jul 8 15:54:55:837985 2014) [sssd] [dyndns_test_ok] (0x1000): Child request returned : Unknown error 14321582280x555d0014 != 0../src/tests/cmocka/test_dyndns.c:222: error: Failure![ FAILED ] dyndns_test_okChild part has finished before the child handler was created.
I have created and attached a patch which is workaround for this issue.
Could someone please take a look and comment this?
one of our users ran into an interesting problem -- her AD
infrastructure was different from the DNS server. Because by default, we
perform update against the server we're connected to, the DNS update
Per Simo's suggestion, I've implemented a new option that allows the
administrator to override the DNS server used for DNS updates.
This is my attempt to add basic integration tests. There are almost no tests
there at the moment and this is mostly about the infrastructure and the way we
might do it.
I will be glad to answer any questions and receive any comments or
suggestions. I'm sure I did a lot of things in a wrong way :)
we talked about implementing ticket #2509 with Pavel in person, but it
would be nice to see if other other developers agree before all the code
is written :-)
The design page is here:
For your convenience, the text of the design page is also copied below:
= Mapping Proxy ID provider names to Kerberos principals =
=== Problem statement ===
Some users are migrating to SSSD from a legacy configuration that consisted
of a traditional UNIX user stored in `/etc/passwd` and managing their
Kerberos tickets either with the use of some GUI tool or just command-line
`kinit`. While these users can use SSSD by configuring the `id_provider`
proxy, very often the name of their UNIX user is different from the name
of their company-wide Kerberos credentials.
This feature helps the above use-case by mapping their UNIX user name to
the Kerberos principal name.
=== Use cases ===
Joe User has a company laptop where his UNIX user has been traditionally
named `joe`. At the same time, his company Kerberos principal is called
`juser(a)EXAMPLE.COM`. Joe would like to start using SSSD to leverage
features like offline kinit without having to rename his UNIX user and
chown all his local files to the corporate user ID.
=== Overview of the solution ===
The Kerberos provider will acquire a new option that describes how are the
user names from the ID provider mapped onto the user part of the Kerberos
principal. The user would then add the appropriate mapping to the `domain`
section of `sssd.conf`.
=== Implementation details ===
A new option `krb5_map_user` would be added to the Kerberos auth code. This
option would have form similar to how we map the LDAP extra attributes,
that is `local_name:krb5_name`. When mapping exists for the user who
is authenticating, the krb5_auth module would use that user name for
calls like `find_or_guess_upn` instead of `pd->name`. We should consider
whether to keep using `pd->name` or introduce another attribute to the
=== Configuration changes ===
A new configuration option tentatively called `krb5_map_user` would be
added. This option is unset by default, which means whatever user name
the ID provider stores will be used.
=== How To Test ===
1. Prepare a Kerberos KDC, add a user principal (`juser(a)EXAMPLE.COM`)
1. Add a local user using `useradd` with name that differs from
Kerberos principal in the name portion. (`joe`)
1. Configure SSSD with `id_provider=proxy` with `proxy_lib_name=files`
and `auth_provider=krb5` pointing to our test KDC
1. Attempt to authenticate using a PAM service. The authentication
should fail and the logs would show authentication as `joe(a)EXAMPLE.COM`
1. Set `krb5_map_user` to `joe:juser` and restart SSSD.
1. Authenticate again. This time, authentication should succeed and the
user's klist output should list `juser(a)EXAMPLE.COM`. The `id(1)` output
should still list `joe`, though.
1. Test that Kerberos ticket renewals still work
1. Test that delayed kinit still works.
=== Authors ===
* Jakub Hrozek <jhrozek(a)redhat.com>
this patch tries to resolve https://fedorahosted.org/sssd/ticket/2588 by
properly handling binary objectGUID values. In general there shouldn't
be an issue because this ID is not used for AD user. But if the binary
value starts with 0x00 there might be issues saving the user object to
the attached two patches add a way to detect pre-1.0 cmocka and adds
compatible definitions in the first patch and uses them to convert a
single unit test.
I found the approach ugly myself, so much that I'm considering converting
all cmocka-based tests to cmocka-1.0 and don't compile the cmocka tests at
all unless 1.0 or later is present on the system. It's not functionality
after all, "just" tests and for CI we could add cmocka-1.0 to the CI