one of the recent patches related to the changes of the sysdb calls to
return ENOENT broke the flow in the lookups by SID. As a result the
request always returned if no result was found in the cache instead of
asking the backend. With the new flow the ldb_result has to be properly
initialized (I remember there was a long discussion about it, but I can't
remember the result, so I fixed it in the caller).
The verify this you need just to look up a SID with is currently not in
the cache, the easiest way is to use an empty cache:
python -c "import pysss_nss_idmap; print pysss_nss_idmap.getnamebysid('S-1-5-21-3456664713-2053453454-4165325232-500')"
Without the patch only an empty list is return, with the patch the SID
is properly looked up by the backend.
I have a bit of a chicken/egg problem with implementing cwrap tests.
Sssd currently requires the config file to belong to root. However, that is
not possible to arrange when running under a regular user, in cwrap tests.
Even though uid_wrapper fakes running under root, the created files still
belong to the real user.
I see two ways out of this: either run under fakeroot, or allow the config
file to (also?) belong to the user sssd is configured to run under (target
While fakeroot will likely work, to me it seems like sweeping the problem
under the rug. The second option seems a bit more natural, especially
considering that the CDB file is explicitly chown'ed to the target user,
Now, since the target user can be configured both at the build time *and* in
the configuration file itself, we'll need to verify file ownership *after*
reading it. Or, can we maybe move user specification to command-line option?
What do you think?
the attached patch adds a public function that opens the PAC responder
socket. The krb5_child uses this call to open a fd towards PAC before
becoming user so that PAC responder is contacted for users from trusted
The original values of memberOf and the original DN are used in the HBAC
evaluation and should be send to the IPA client for AD users via the
extdom plugin. The attached patches adds those attribute to the response
of of the getorig request. No changes in the extdom plugin are needed.
Since originalMemberOf is a multi-value attribute fill_orig() must be
able to handle multi-value attributes. The first patch adds the needed
changes while the second refactors fill_orig() a bit. To make reviewing
easier I didn't squash them together. The last patch adds the new
attributes to the getorig request.
On 01/18/2015 03:24 AM, Traiano Welcome wrote:
> Hi Dmitri
> On Tue, Dec 30, 2014 at 12:17 AM, Dmitri Pal <dpal(a)redhat.com> wrote:
>> On 12/24/2014 01:04 AM, Traiano Welcome wrote:
>>> Hi List
>>> I have a large number of legacy hosts with upper-case host names, that
>>> I'd like to configure as IPA clients. However ipa client refuses to
>>> accept upper case hostnames during configuration time.
>>> I think this derives from the fact that the kerberos5 database stores
>>> host names in a case sensitive way and requires that the DNS hostname
>>> matches the server hostname case.
>>> My question is: Is it mandatory that the hostname be lower-cased, or
>>> is there a safe workaround that will allow IPA client to work with
>>> hosts that have upper case host names ?
>>> Thanks in advance!
>> See man sssd-ipa
>> ipa_hostname (string)
>> Optional. May be set on machines where the hostname(5) does not
>> reflect the fully qualified name used in the IPA domain to identify this
>> AFAIR you use this setting for the cases when you want the actual machine
>> name be different than the one IPA has.
> It looks like I would have to add this parameter in the sssd.conf
> before running the ipa client configuration. In that case, would the
> configurator not overwrite this parameter ?
> Or is there some way to provide this option to ipa-client-install initially?
AFAIR then you have to configure it manually.
But this question belongs more to SSSD list so I am moving it there.
Also I think the option is to change the name of the host, enroll
automatically, then change it back and update the configuration.
But I would prefer SSSD gurus to confirm that.
>> Thank you,
>> Dmitri Pal
>> Sr. Engineering Manager IdM portfolio
>> Red Hat, Inc.
>> Manage your subscription for the Freeipa-users mailing list:
>> Go To http://freeipa.org for more info on the project
> Thanks in advance,
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.