#742 Overriding LDAP attribute values
Closed: Fixed None Opened 13 years ago by somlo.

I am currently dependent on the ability to override LDAP attribute values. In nss_ldap.conf, I do that using e.g.

  nss_override_attribute_value gidNumber 100

to get everyone's default group to be 'users', rather than whatever "unusual" value was picked by the LDAP server operators a long, LONG time ago, and I don't have the political clout to get fixed anytime soon :)

To be precise, I'm not talking about something like "ldap_user_gid_number <string>", which is the equivalent of "nss_map_attribute gidNumber <string>", which works fine, but merely maps between client and server attribute naming conventions. Rather, I want to supply my own value for an attribute, which would override whatever the server may or may not supply.

Please consider offering a similar value-override feature in sssd-ldap.

Thanks,
--Gabriel


Patches for this feature will be welcome, but at our status meeting today we've decided that for the immediate future, this doesn't line up with our goals for SSSD.

The purpose of centralized management is to keep all of the information in one place, easily modified. Features like this decentralize identity data and make it more difficult for administrators to keep track of. SSSD is meant to be a facilitator of central management.

component: SSSD => LDAP Provider
milestone: NEEDS_TRIAGE => SSSD Deferred

In large environments, an administrator may not have control over the presence or correctness of certain attributes in a directory. Also, certain systems may not need or want certain attributes assigned to users.

Use Cases:

Example 1: The default shell might be csh, which might not be installed on a system configured for directory authentication. For use in some environments, such as file servers, no shell might be necessary.

Example 2: Overriding the root home directory is useful on systems where users might have networked home directories, or have them mounted in a non-standard location.

Example 3: The LDAP Directory being used does not have certain attributes defined. Being able to specify them would be useful.

This does not conflict with the stated goal of centralized management. It still keeps users on centralized identification and authentication mechanisms. Allowing overrides would merely allow administrators to adapt the directory for each situation encountered.

upgrade: => 0

I moved this to NEEDS_TRIAGE again, because I think there are some good new arguments to reconsider this ticket.

milestone: SSSD Deferred => NEEDS_TRIAGE

Who defines which attributes is OK to override and which attributes have to come from the directory? If we provide a way to override the centrally managed values in a generic way how we make sure that local setup does not ignore or overwrite the proper centrally provided attributes? Though the system might be configured to not use centrally managed attributes at all I see a danger in ability to override any attribute locally. The system would seem to provide centrally enforced/provided information but in reality it will use local settings. I am worried that the feature will leave a lot of room for abuse if not properly contained to a very limited and predefined set of attributes.

Replying to [comment:4 dpal]:

Who defines which attributes is OK to override ?

Root on the client system, of course.

Either it's the same person/group running both the LDAP server and the client systems,
in which case everything is great (and if I were that person/group I'd ensure that no
overrides would be necessary in the first place, to minimize my workload).

Alternatively, local/client root does NOT have sufficient control or influence over the
LDAP server, which is the reason why overrides are necessary to begin with. Local root
MUST be trusted to make the right decision here -- if one doesn't trust root, one should
not be logging into that machine in the first place, so all concerns voiced above are
already moot.

It is still within the LDAP server admin's power to decide whether to allow any individual
client to use the directory, by requiring authentication/encryption (or not).

To me, this feels like a case of mechanism vs. policy (http://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy). Mechanism is "allow local root to override whatever
they think is right". Policy is "LDAP admin can allow unauthenticated lookups or not. If not,
they can hold authenticated users accountable for their behavior".

Just my humble opinion...
Thanks, --Gabriel

Replying to [comment:5 somlo]:

Replying to [comment:4 dpal]:

Who defines which attributes is OK to override ?

Root on the client system, of course.

Either it's the same person/group running both the LDAP server and the client systems,
in which case everything is great (and if I were that person/group I'd ensure that no
overrides would be necessary in the first place, to minimize my workload).

Alternatively, local/client root does NOT have sufficient control or influence over the
LDAP server, which is the reason why overrides are necessary to begin with. Local root
MUST be trusted to make the right decision here -- if one doesn't trust root, one should
not be logging into that machine in the first place, so all concerns voiced above are
already moot.

It is still within the LDAP server admin's power to decide whether to allow any individual
client to use the directory, by requiring authentication/encryption (or not).

To me, this feels like a case of mechanism vs. policy (http://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy). Mechanism is "allow local root to override whatever
they think is right". Policy is "LDAP admin can allow unauthenticated lookups or not. If not,
they can hold authenticated users accountable for their behavior".

Just my humble opinion...
Thanks, --Gabriel

I see a fundamental problem with this approach. Once we implement something like this there is no control left to the LDAP admin to define centrally managed attributes that can't be overwritten.
Local root should be trusted to the least level possible. The feature will make him too powerful. I am not against making him powerful but the LDAP admin should have central control over it. So I would say that mechanism should be "allow local admin to override attributes unless the central admin prevents him centrally from doing so". And the policy will be to whether or not the LDAP admin cares what attributes are controlled.
So IMO the right logic would be:
- SSSD looks for a special multivalue configuration attribute "allowedOvewride".
- If it is not specified - all overides are allowed
- If it is specified then it will hold the list of the attributes that are allowed to be locally overwritten.
Alternatively there can be a "overrideNotAllowed" attribute that lists the attributes that are not allowed to be overwritten. I do not know which approach is better but I am not comfortable leaving all control to the local root.
We need to think not only about the convenience but also the abuse and the uncontrolled feature would lead to uncontrollable abuse.

We've talked about this elsewhere before. We definitely need to have the ability to override certain attributes on the client system. Dmitri, I think you're forgetting that root is $DEITY for all things on the client machine. There's no way to prevent root from changing attributes at whim if they want to (for example, root may put a special LDAP proxy on the local machine that would intercept requests and make the change). However, root should not have to jump through so many hoops.

Certain attributes are obvious candidates for overriding. As described above, the user's shell binary and home directory path really are must-haves. If a user's default shell is set to csh, but not all machines he logs into have csh, then it effectively becomes an access denial. On those machines, it needs to be possible to have the shell set to e.g. bash.

Similarly, NFS-mounted home directories may be relevant. There are machines on the network that may prefer having their NFS-mounted homedir located in another path on the filesystem (for one reason or another). This is something we need to be able to override.

Right now, I'm generally opposed to creating a generic override feature like {{{nss_override_attribute_value}}}, as I'd rather we provided specific options for the attributes in question.

For example:

ldap_user_home_directory_template = /path/to/homedir/%u

Where the template would have special escape characters similar to those used by {{{krb5_ccachedir}}}

Similarly, I'd like for us to have

ldap_user_shell_override = /bin/tcsh

I don't know that we would necessarily want to allow overriding any of the other attributes, however. I can't think of a situation where overriding username, UID, GID or GECOS with a global value would make any sense.

Replying to [comment:7 sgallagh]:

I can't think of a situation where overriding username, UID, GID or GECOS with a global value would make any sense.

Agreed on UID and GECOS (they're kind of the reason why I want to use LDAP in the first place). However, in my particular case, I needed to override home_dir, shell, and GID. Here's my situation:

As part of running IT for an academic department at a university, I want to set up a computer lab based on Fedora. Keeping track of user names and passwords is silly, since central campus IT already runs Kerberos and LDAP, the latter containing lots of useful data.

However, they're really old school, and have been doing this for a very long time. By default, everyone's shell defaults to /bin/tcsh, everyone's home dir is an AFS path, and everyone's GID is set to 10. Legend has it that used to be the "staff" group on some long lost flavor of Unix, but nobody knows for sure. They'd all like to switch everyone's GID to 100 (users group on most modern Unix flavors), but nobody has the time and energy to figure out if anything actually relies on the current GID value.

I can install tcsh and even AFS (e.g. from rpmfusion), although I appreciate your agreeing with me that these should be easy to override.

But what I would really appreciate is being able to override the GID with "100", and place everyone I allow on my machines into the "users", rather than "wheel" group. Central IT might deliberate for a few Fedora release cycles before deciding on a course of action regarding the
default LDAP GID value, and I'd like to use, not fight, my preferred software platform in the
mean time.

I'm still stuck with pam_krb5 and nss_ldap for now (because of this ticket and also #463), but
would love to switch to sssd in the future, since it feels much cleaner and much more
efficient. I feel bad for not having the spare cycles to send patches myself, but would also
hate to see you all put a lot of effort into selecting just which attributes you'd support
overrides for, only to have someone else pop up with a well-justified new list they can't live
without, and so on.

Why do you feel so reluctant about a simple, general override mechanism, to be used with discretion by the client's administrator ?

Ok, I suppose I can see your argument for the GID override (though in my heart of hearts I feel that this is something best solved on the central server).

I don't think a general override mechanism makes sense at this point, honestly. NSS only allows us to return UID, username, Primary GID, GECOS, shell and homedir.

An override of UID can never make sense, since it would result in all LDAP users having the same local identity. So we don't need to include that.

An override of username would only result in mislabeling and general misbehavior on the client system. So it's in our best interest to disallow this.

An override of GECOS is similarly useless, since it would result in all users having the same extended information. While there ARE platforms where the GECOS is used for something other than the user's full name, it's both rare and virtually guaranteed to have been set up carefully on the server-side. If we ever did need to support this feature, I suspect it would require a much more comprehensive and rules-based mechanism than a simple attribute override.

For the Primary GID, I can see your argument above. This attribute could be made to override to a single numeric value. Straightforward and would match the {{{nss_override_attribute_value}}} approach.

For the shell, as we've discussed above, there are two things I might like to change here.
1. We should allow all users' default shell on a client system to be replaced by a local value, in the traditions of {{{nss_override_attribute_value}}}
2. Individual users should be allowed to set their own values for the shell using a command-line tool. This would maintain a value in the SSSD cache on the local machine that would overrule both the central server and the local override.

Finally, for the home directory, as I described in an earlier comment, I'd like for this to be configurable as a template expansion, rather than a hard path. This way it's possible to manage completely different filesystem layouts on the client machines than the central system supports (e.g. Imagine an arrangement where the home directory was mounted at /mnt/uid/home instead of /mnt/home/username)

Since each of these options would be best served by different semantics (and it would be difficult to create a union of these semantics), I think offering separate options would make the most sense.

Replying to [comment:9 sgallagh]:

Ok, I suppose I can see your argument for the GID override
(though in my heart of hearts I feel that this is something best solved on the central server).

I trust central IT with my auth(z/n), but don't have enough clout to make them fix anything they don't also see as a priority :) Allowing me to override GID allows us to work together (even if suboptimally), rather than not at all. Such is life in large organizations, for better or worse.

I don't think a general override mechanism makes sense at this point, honestly. NSS only allows us to return UID, username, Primary GID, GECOS, shell and homedir.

Ah, now I understand -- talking about overriding anything besides these six makes no sense, as they wouldn't be used by nss, sssd, etc in the first place. Given this limited set of attributes, I get why you'd want to treat the exceptions individually rather than via a generic mechanism. Overriding uid, username, or gecos would be unsupported not because you're trying to stop me from being naughty, but simply because it would make absolutely no sense for me to attempt that, under any use case.

Since each of these options would be best served by different semantics (and it would be difficult to create a union of these semantics), I think offering separate options would make the most sense.

And thanks for taking the time to explain it -- the different semantics you described above make perfect sense now !

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.6.0

Fields changed

owner: somebody => sgallagh

Fields changed

owner: sgallagh => jhrozek

Fields changed

patch: => 0
status: new => assigned

I'm interested in overriding certain attributes from Active Directory. Currently I have to use nss_sss in proxy mode back to pam-nss-ldapd to accomplish this. It would be great if sssd could do this itself.

cc: => ktdreyer

Replying to [comment:15 ktdreyer]:

I'm interested in overriding certain attributes from Active Directory. Currently I have to use nss_sss in proxy mode back to pam-nss-ldapd to accomplish this. It would be great if sssd could do this itself.

This is being worked on. Can you tell us which attributes you override, so we don't miss anything?

We had a detailed discussion on IRC on the topic of overriding user shell with Simo and Stephen.

Summary - users should not be able to override their shell themselves. It is not a manageable solution in a centralized environment.

Instead, we will do the following: Add two new options, one providing the list of allowed shells and one providing a fallback shell. The logic works as follows:

1) If a shell is present in /etc/shells on the local machine, use it (Rationale: The user has a valid shell on the system)

2) If a shell is present in allowed_shells but not on the local machine, use the fallback shell

3) If a shell is neither in allowed_shells nor on the local machine, use a nologin shell (typically /sbin/nologin)

Fields changed

patch: 0 => 1

I'm overriding home directories and shells. Home directories can be addressed in #551. The proposal in comment 17 will cover the shells.

My two cents on what overrides should be allowed:
To be honest, I don't see why sssd should nitpick which attributes are or are not allowed to be override-able. That's a policy / governance problem for each site, not a software problem. Why not just make every attribute override-able / templatable-able and be done with it ? :)

To be honest, I don't see why sssd should nitpick which attributes are or are not allowed to be override-able. That's a policy / governance problem for each site, not a software problem. Why not just make every attribute override-able / templatable-able and be done with it ? :)

Because different attributes have different meaning, use and format. And there is only only a predefined subset of attributes that POSIX knows about. It would make sense to have more generic rules for other attributes when they become exposed via SSSD's inforpipe interface but for PISIX attribute override it makes sense to implement a special logic per attribute as override logic might be (and already showed in fact that it is) different from attribute to attribute. There is a bug that has some analysis of the different attributes in the discussion. Do not remember which one though.

master:
d9d716b (homedirs)

068dbee (shells)

54af51d (primary GID)

resolution: => fixed
status: assigned => closed

Backported to 1.5.9

milestone: SSSD 1.6.0 => SSSD 1.5.9

Fields changed

rhbz: => 0

Metadata Update from @somlo:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.5.9

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1784

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata