Bug 9946 - winbind name normalization shortcomings and bugs
Summary: winbind name normalization shortcomings and bugs
Status: NEW
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: Winbind (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Michael Adam
QA Contact: Samba QA Contact
Depends on:
Reported: 2013-06-12 09:17 UTC by sambabug.lb
Modified: 2014-09-10 22:02 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description sambabug.lb 2013-06-12 09:17:42 UTC
I'm trying to configure my linux servers to join my AD domain and authenticate against that, in ads mode. Everything works find except that I have some names in AD containing blanks (e.g. "Domain Users") and that is causing issues on some linux scripts. I hoped this could be solved using samba option "winbind normalize names = yes" but actually this features seems to have more problems than it solves.

- one can have names in AD both with blanks and with underscores, e.g. "user_1" and "user 2" (or user 3_bis).
Using "normalize names" (and no aliasing) would make "user 2" appear as "user_2" in linux (good), but would also make "user_1" unusable as winbind would look it up as "user 1" on AD (bad). This could be "worked around" by explicitly adding an alias as "user_1 = MYDOM\user_1" which would disable the blank replacement (as aliasing a name disables blank replacement), but this can get impractical if there are many names with underscores in AD.

- this also breaks domains with underscores as e.g. MY_DOM\myuser would become "MY DOM\myuser" after normalize_name_unmap, which is not even a valid NETBIOS name in Win2k+. The explicit map workaround would definitely be useless in this case as you would need to list ALL of your AD names.

- pam_mkhomedir fails for user names containing blanks even when normalization/aliasing is enabled; in fact, the %U in the homedir template is replaced with the original AD name (with blanks), and then the command used to create the homedir doesn't properly handle the blanks and fails. I think both these issues should be addressed (e.g. introduce an alternate template letter for the aliased name; and in any case support creating home dirs with blanks for cases where people prefer to keep the blanks).

In our AD we have a domain name with an underscore and both names with blanks (the AD builtins) and with underscores. I don't see any winbind configuration that can possible work to avoid the blanks in linux in this case (so we are forced to have names with blanks in Linux, which sometimes break things).

A) enhance the "normalize names" option to:
 1) allow to enable aliasing without automatically also enabling blank substitution
This would already work in our case as we could use idmap hash and define a map like "domain_users = MY_DOM\Domain Users" (for all names with blanks which are just a few) and still have all other users/groups work fine, including those with underscores;

 2) optionally exclude domain names from the blank substitution (which should be the default for win2k+ domains as blanks are not allowed since that version).
This alone wouldn't solve in our case, but would be fine for anyone with an underscores in the domain names and not in user/group names;

 3) optionally enable it only for known builtin AD names  (for cases when one has been careful enough not to add names with spaces, but still has the builtin "Domain Users", "Domain Admins",...)

 4) allow to specify what to replace blanks with (e.g. a double underscore instead of a single underscore) - so that even names in AD with (non-double) underscore would still work fine (as it is in our case);

 5) eventually support some more advanced normalization rules (e.g. to map other special chars beside blanks)

B) enhance the aliasing feature to:
  6) split the aliasing plugin from the idmap plugin so that one can use e.g. the name_map aliasing (from hash idmap) with the adex idmap, or with one of the older idmaps (maybe this is already possible)
  7) in the hash/name_map aliasing, support more advance aliasing rules with patterns instead of fixed single key = value lines (maybe with regex or some kind scripting)

Points 1-4 seem quite easy to implement (I can probably do it), however they would be very difficult to maintain in a production environment unless added to official sources.