Bug 10619 - Make --use-rfc2307 default for provisioning/classicupgrade
Summary: Make --use-rfc2307 default for provisioning/classicupgrade
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Tools (show other bugs)
Version: unspecified
Hardware: All All
: P5 enhancement (vote)
Target Milestone: 4.3
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks: 11924
  Show dependency treegraph
 
Reported: 2014-05-19 16:39 UTC by Marc Muehlfeld
Modified: 2016-06-07 16:15 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Muehlfeld 2014-05-19 16:39:24 UTC
--use-rfc2307 should be enabled per default on provisioning/classicupgrade. It does not bring any disadvantages.




Use case 1:

We often have requests on the mailing list, about how to enable RFC2307 and the NIS Extensions. I meanwhile wrote a HowTo about that: https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC.



Use case 2:

Also --use-rfc2307 automatically does the schema extension (ypServ30.ldif). In that place of the AD, the Windows tools like ADUC track the next free UID/GID for creating users. samba-tool could use this, too and would automatically be ADUC compatible. But this would be a new feature request, if --use-rfc2307 is implemented as default.
Comment 1 Andrey Repin 2015-05-05 07:29:01 UTC
Main argument: Forget for a moment about Windows.

Think about environment Samba is run within.

It is a *NIX application, it offers services deeply based on system functionality (file access, authentication and authorization, et cetera), and to work transparently it needs consistent translation from internal to system attributes at all times.

Currently, there's no consistency. Or, more precisely, the consistency can only be achieved, if installation is not using RFC2307 attributes at all.

However ludicrous it may sound - it is true.

Samba uses two sources for mapping OS user/group identifiers to the internal (windows) SID's. idmap.ldb mapping (builtin) SID's to uid/gid's on domain controller and RFC2307 attributes from SAM.

You may say that SAM is authoritative, thus there's no conflict. However, that may only be true for new provisions (and even then, I'm not entirely sure it is true). The issue is more apparent, when you upgrade existing domain.

In my case, the upgrade created idmap.ldb with builtin SID's map starting from 30'000 (the idmap range for domain in the initial smb.conf), then imported existing user/group base with uids starting in the same 30'000 range. As a result, the idmap.ldb mapped "Authenticated users" gid 30'002 became "RemoteUsers" from SAM, and the rights set on sysvol and netlogon shares got screwed completely.