[PATCH] LDAP: Only convert direct parents' ghost attribute to member
by Jakub Hrozek
[PATCH 1/2] SYSDB: Use the add_string convenience functions for managing
ghost user attribute
Using the convenience function instead of low-level ldb calls makes the
code more compact and more readable.
[PATCH 2/2] LDAP: Only convert direct parents' ghost attribute to member
https://fedorahosted.org/sssd/ticket/1612
I'm not too happy with the originalDN attribute exposed in the
sysdb_add_user/store_user functions but it seemed like a better way
than grabbing the attribute from the extended attributes in the "attrs"
array. At the same time, we need to adjust the attributes during all user
adds, not just during sdap_store_user from the LDAP provider. Ideas on
how to make the process cleaner are welcome.
This patch changes the handling of ghost attributes when saving the
actual user entry. Instead of always linking all groups that contained
the ghost attribute with the new user entry, the original member
attributes are now saved in the group object and the user entry is only
linked with its direct parents.
As the member attribute is compared against the originalDN of the user,
if either the originalDN or the originalMember attributes are missing,
the user object is linked with all the groups as a fallback.
The original member attributes are only saved if the LDAP schema
supports nesting.
11 years, 5 months
FW: Wrong DB version (got 0.13 expected 0.10)
by Ariel Barria
> Date: Tue, 20 Nov 2012 17:46:57 +0100
> From: okos(a)redhat.com
> To: sssd-devel(a)lists.fedorahosted.org
> CC: olivares73(a)hotmail.com
> Subject: Re: [SSSD] Wrong DB version (got 0.13 expected 0.10)
>
> On 11/20/2012 04:08 PM, Ariel Barria wrote:
> > thanks.
> >
> > well, this is a installation from scratch.
> > 1. Install fedora in virtual machine.
> > 2. update fedora
> > 3. git clone git://fedorahosted.org/git/sssd.git
> > 4. create aliases
> > alias configure='../configure ........
> > 5. I follow the steps the Build.txt with mkdir -p parallelbuilddir && cd
> > parallelbuilddir && configure && make
> > 6. [root@dev1 parallelbuilddir]# ./sssd -d9 -i
> > 7. result in sssd.txt
> >
> > had tried deleting the contents of /var/lib/sss/db and showed the same
> > message.
> >
> >
> > > Date: Tue, 20 Nov 2012 08:45:38 +0100
> > > From: okos(a)redhat.com
> > > To: sssd-devel(a)lists.fedorahosted.org
> > > Subject: Re: [SSSD] Wrong DB version (got 0.13 expected 0.10)
> > >
> > > On 11/19/2012 10:26 PM, Ariel Barria wrote:
> > > >
> > > > Hi.
> > > > for orientation please.
> > > > I do this ./sssd -d9 -i
> > > > and output is this
> > > > *Wrong DB version (got 0.13 expected 0.10)*
> > > > What should I upgrade?
> > > > thanks
> > > >
> > > >
> > > > _______________________________________________
> > > > sssd-devel mailing list
> > > > sssd-devel(a)lists.fedorahosted.org
> > > > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> > > >
> > > Have you recently downgraded SSSD?
> > > You have database from version 1.9.1 or higher and apparently using sssd
> > > 1.9.0.beta1. You can either upgrade sssd to 1.9.1 or higher, or delete
> > > cached files in DB_PATH (default: /var/lib/sss/db/), but if you remove
> > > those, you'll loose all of your cached credentials.
> > >
> > > Ondra
> > >
> > > p.s.: this message would probably be more suitable for sssd-users list
> > > --
> > > Ondrej Kos
> > > Associate Software Engineer
> > > Identity Management
> > > Red Hat Czech
> > >
> > > phone: +420-532-294-558
> > > cell: +420-736-417-909
> > > ext: 82-62558
> > > loc: 1013 Brno 1 office
> > > irc: okos @ #brno
> > > _______________________________________________
> > > sssd-devel mailing list
> > > sssd-devel(a)lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> >
> >
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> >
> Hi Ariel,
>
> I tried to reproduce this, but it works like a charm. My guess still is
> that you're somehow mismatching sssd versions, because:
>
> *sssd-1.8.5-2* (F17 repo) uses DB version *0.10*
> *sssd-1.9.3* (git master) uses DB version *0.13*
>
> so it seems, that you've created DB with compiled upstream sssd and are
> trying to read it with older version.
>
> could you post what does the following say?
>
> sssd --version
>
> ./sssd --version #from parallelbuilddir
[root@dev1 parallelbuilddir]# ./sssd --version
1.9.90
I will search this
> ldbsearch -H /var/lib/sss/db/cache_example.com.ldb -b cn=sysdb "version=*"
>
> Thanks
>
> Ondra
> --
> Ondrej Kos
> Associate Software Engineer
> Identity Management
> Red Hat Czech
>
> phone: +420-532-294-558
> cell: +420-736-417-909
> ext: 82-62558
> loc: 1013 Brno 1 office
> irc: okos @ #brno
11 years, 5 months
[PATCH] LDAP: Make it possible to use full principal in ldap_sasl_authid again
by Jakub Hrozek
The behaviour of ldap_sasl_authid was changed in
e81a816cddab4a62f263d1a0274d5d3f101e8e0f so that it no longer accepted full
principal, but only hostname. The realm was read from the (undocumented)
ldap_sasl_realm option.
Moreover the "hostname" had to be specified in exactly the format that would
match the keytab later, ie if the first match was host/hostname, the option
would have to be specified as host/hostname, otherwise the user got an error.
I also found out that the principal selection is only used in IPA and AD
providers, but I'll file a separate ticket to track that. Right now, I'm
mostly interested in fixing the regression.
The attached patched modify that behaviour:
[PATCH 1/3] MAN: document the ldap_sasl_realm option
The option was completely undocumented.
[PATCH 2/3] LDAP: Provide a common sdap_set_sasl_options init function
The AD and IPA initialization functions shared the same code. This patch
moves the code into a common initialization function.
[PATCH 3/3] LDAP: Make it possible to use full principal in ldap_sasl_authid again
When the guessing of principals was introduced, we changed the existing
behaviour and instead of allowing both host/hostname@REALM and
host/hostname, only the latter worked and the realm was always appended
from the (then undocumented) ldap_sasl_realm option.
This patch changes the behaviour to be more backwards-compatible -- if
the ldap_sasl_authid contains the @-sign, then the ldap_sasl_realm is
not always appended.
The strict requirement of checking the requested authid/realm against
the one found in keytab was also kind of relaxed because it didn't
really work. For example when hostname was requested and the keytab
matched host/hostname first, the code blew up.
https://fedorahosted.org/sssd/ticket/1635
11 years, 5 months
[PATCH] KRB5: Fix UPN size check
by Jakub Hrozek
Compare_principal_realm ran a sanity check on UPN size and realm size,
but the check was not correct in case the realms were different and the
UPN realm was much shorter then the "realm" parameter.
11 years, 5 months
simple access provider / non-sss users
by Paul B. Henson
In our current RHEL5 deployment, we use pam_listfile to control access
to our servers. While I was putting together our sss config for RHEL6, I
initially thought I could use the simple access provider to replace it.
However, we have both central accounts as well as local service accounts
on some servers. While we try to avoid scenarios where a local service
account needs to log in directly, in some cases it is unavoidable and as
such some of them exist in our pam_listfile configuration.
The sss pam provider always returns user unknown for these local users
in the account module, never getting to the access control. I would
consider it useful for the simple access provider to be able to control
access based on the allow/deny lists for users that aren't part of any
sss domain, without that capability it cannot replace pam_listfile. I
took a look, and unfortunately making such a change seems far from
trivial 8-/.
What are thoughts on such functionality? From a design perspective, do
you prefer that this access control mechanism only function with sss
domain users? From an abstract perspective, it could easily process
allow/deny for users that it doesn't know about. Groups, OTOH, would be
more problematic. I think all of our current pam_listfile configuration
for local accounts is based on users though.
The other option I considered was adding a second sss domain that
proxied nss_files such that sss was aware of local users. This seemed a
bit kludgy, more so than just continuing to use pam_listfile, which is
what we ended up doing.
Thanks...
11 years, 5 months
[PATCH 0/1] RFC: Fix group memberships for subdomain users
by Simo Sorce
This patch changes the way subdomain users are stored in the database.
The reason for changing the way we do it is that the sysdb code, before the
subdomain patches were added assumed a single domain per cache file. This
assumption beled in many other interfaces including the way users are read and
returned in the nss responder, as well as potentially how hbac and sudo handle
rules for checking if users are part of a rule.
In order to make sure subdomain users are univocally recognized as such the
safest way is to change how users are saved and always save subdomain users
with sully qualified names.
With this change we solve one of the most eveident issues we currently have
where subdomain users are not listed fully wualified in group membership when
they should.
The side effect of this change is that cache files need to be removed if the
admin decides to change the formatting string for representing fully qualified
users. An action like this has many other important consequences on the system
so I think this limitation is perfectly reasonable.
This patch is in RFC status because I haven't dealt with database migrations
to fix existing subdomain users. Would it be acceptable to simply remove
all subdomain user entries on upgrade ?
Also in order to fix this important issue for 1.9 I have refrained from
significantly changing sysdb interfaces or other code around domain
manipulation. I think such changes are necessary in future. The consequence
of not changing sysdb interfaces is that knowledge of the fact the subdonains
users need to be fully qualified bleeds in various other callers. I hope I
caught all the callers that need to know about this difference but I haven't
yet checked sudo related code for example.
The patch is so far fully tested and allows password based logins with full
HABC checking. getent passwd/group commands also return the extected outputs.
Please review carefully.
Simo Sorce (1):
Refactor the way subdomain accounts are saved
src/db/sysdb_search.c | 17 +++++++++++-
src/providers/data_provider_be.c | 11 +++++++
src/providers/ipa/ipa_s2n_exop.c | 54 +++++++++++++++++++++++++++++++++++---
src/responder/nss/nsssrv_cmd.c | 36 +++++++++++++++++++++++--
src/responder/pac/pacsrv_cmd.c | 15 +++++++++-
src/responder/pac/pacsrv_utils.c | 52 ++++++++++++++++++++----------------
src/responder/pam/pamsrv_cmd.c | 18 ++++++++++++-
src/util/domain_info_utils.c | 2 +-
8 files changed, 170 insertions(+), 35 deletions(-)
11 years, 5 months