Bug 6322 - Documentation to idmap_ad is outdated.
Documentation to idmap_ad is outdated.
Status: RESOLVED FIXED
Product: Samba 3.6
Classification: Unclassified
Component: Winbind
3.6.8
x86 Linux
: P3 normal
: ---
Assigned To: Michael Adam
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-04 10:00 UTC by Edgar Holleis
Modified: 2012-10-02 17:53 UTC (History)
5 users (show)

See Also:


Attachments
Full logs and config of the reported issue. (19.48 KB, application/x-compressed-tar)
2009-05-04 10:02 UTC, Edgar Holleis
no flags Details
manpage update for idmap_ad (1.62 KB, patch)
2010-12-07 14:43 UTC, Michael Adam
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Edgar Holleis 2009-05-04 10:00:29 UTC
works: 2:3.2.3-1ubuntu3.4
broken: 2:3.3.2-1ubuntu3

Winbind specific parts of smb.conf:
> log level = 3 idmap:10 winbind:10
> workgroup = XXX
> security = ADS
> realm = XXX.XXXXXX.XX.XX
> password server = *
> winbind separator = \\
> winbind enum users = yes
> winbind enum groups = yes
> idmap backend = ad
> idmap config DOMAIN : schema_mode = rfc2307
> winbind nss info = template
> winbind use default domain = yes
> winbind offline logon = yes
> idmap uid = 1100-49999
> idmap gid = 1100-49999
> template shell = /bin/bash
> template homedir = /home/%u

Details:

Winbind correctly resolves:
  User-Name->SID (wbinfo -n), Group-Name->SID (wbinfo -s)
What doesn't work:
  SID->UID (wbinfo -S), UID->SID (wbinfo -U), 
  SID->GID (wbinfo -Y), GID->UID (wbinfo -G)

The docs suggest stacking a writable idmap-backend above AD. That doesn't help, since Samba ends up allocating new (and incorrect) mappings for all UIDs in the writable backend instead of using the ones from AD.

Full logs and full config attached.
Comment 1 Edgar Holleis 2009-05-04 10:02:18 UTC
Created attachment 4111 [details]
Full logs and config of the reported issue.
Comment 2 Edgar Holleis 2009-05-04 10:06:24 UTC
Also tracked at https://bugzilla.samba.org/show_bug.cgi?id=6322
Comment 3 Volker Lendecke 2009-05-04 10:16:57 UTC
You have the string NT_STXXUS_MEDIA_WRITE_PROTECTED in your logfile. This is definitely not upstream Samba, I don't see where this could come from in Samba. Please contact your vendor for the patches.

Thanks,

Volker
Comment 4 Edgar Holleis 2009-05-04 10:22:57 UTC
That's NT_STATUS_MEDIA_WRITE_PROTECTED, not NT_STXXUS_MEDIA_WRITE_PROTECTED

The XX is an artifact of
  sed -i 's/AT/XX/g' *
which I did to fuzz the domain name, where the last component is AT. My bad.

However, that does not explain why it does work with samba 3.2.3. 
Comment 5 Michael Adam 2009-05-05 00:54:45 UTC
Right, currently the AD backend does only work properly when
configured with an explicit domain configuration like this:

idmap config DOMAIN : backend = ad
idmap config DOMAIN : range = 10000-49999
idmap config DOMAIN : schema_mode = rfc2307

with default config using the tdb backend as a fallback
for other domains like BUILTIN and trusted, e.g.:

idmap backend = tdb
idmap uid = 50000-99999
idmap gid = 50000-99999

I am afraid this is not properly documented so this can be
considered a bug in the man pages. And of course it is a feature
lacking from the idmap_ad module, that it can not be run as the
default idmap backend. This is due to the internal structure of
the idmap_ad connection manager and the way the idmap code handles
the default domain. I had the plan of extending this, so that
idmap_ad could also be used as default backend, but I did not find
the time yet.

Strangely, Günther Deschner has reportet a setup like this to
be working (idmap_ad as default). Putting Günther on cc...
Comment 6 Edgar Holleis 2009-05-05 10:06:57 UTC
Michael Adam's solution works, thanks. 

I tried adding a writable backend before, but apparently didn't get the details right. Before, it would allocate new (and incorrect) mappings in the tdb backend, instead of resolving the mappings from AD. 

I'm not totally sure in how far Michael Adam's configuration differs from what I've tried. Apparently I missed the part about the ranges, which have to be mutually exclusive. I think I left the ranges as they were in the old configuration and assumed winbind would know what to do. I used to think of the ranges more as a hint to winbind, since the uids and gids are already fixed in the AD leaving winbind exactly zero choice.

I suggest adding a notice to the manpage "idmap_ad", along the lines of:
"Note: The configuration of idmap_ad have changed considerably since the Samba 3.2. Idmap_ad now *requires* an additional, writable idmap-backend. See the examples-section below. The UID-ranges assigned to idmap_ad must be disjoint of the ragnes assigned to the writable backend."
Comment 7 Michael Adam 2009-05-13 01:41:48 UTC
(In reply to comment #6)
> Michael Adam's solution works, thanks. 

Thanks for the feedback.

> I tried adding a writable backend before, but apparently didn't get the details
> right. Before, it would allocate new (and incorrect) mappings in the tdb
> backend, instead of resolving the mappings from AD. 
> 
> I'm not totally sure in how far Michael Adam's configuration differs from what
> I've tried. Apparently I missed the part about the ranges, which have to be
> mutually exclusive. I think I left the ranges as they were in the old
> configuration and assumed winbind would know what to do. I used to think of the
> ranges more as a hint to winbind, since the uids and gids are already fixed in
> the AD leaving winbind exactly zero choice.
> 
> I suggest adding a notice to the manpage "idmap_ad", along the lines of:
> "Note: The configuration of idmap_ad have changed considerably since the Samba
> 3.2. Idmap_ad now *requires* an additional, writable idmap-backend. See the
> examples-section below. The UID-ranges assigned to idmap_ad must be disjoint of
> the ragnes assigned to the writable backend."

Thanks for the suggestion, too.
It is right that we should make this more clear in the docs.

Should we make this doc-request a real bug?

Michael
Comment 8 Michael Adam 2010-12-07 14:43:54 UTC
Created attachment 6123 [details]
manpage update for idmap_ad

I pushed this manpage update to idmap_ad to master and v3-6-test.
Should we add it to 3.5.7, too?
Comment 9 Klaus Steinberger 2011-04-19 09:41:42 UTC
There seems to be one more change in 3.5.x idmap, which should be changed or at least documented:

The mapping seems to work only if the primary windows group of the account has unix attributes.

We synchronize our accounts from a novell edirectory to AD.

Most of the users have the gidNumber 10000 (group campususer) as primary unix group

The driver makes them to member and primary group of "Domain Users" which has no unix attributes.

Then for example "wbinfo -i" returns:

[root@z-sv-test samba]# wbinfo -i AD\\pcadmin
Could not get info for user AD\pcadmin
[root@z-sv-test samba]# 


If we add campususer (which has unix attributes) as the  primary group to a user, wbinfo then works:

[root@z-sv-test samba]# wbinfo -i AD\\Guinea.Pig
AD\guinea.pig:*:10007:10000:Guinea Pig:/home/g/Guinea.Pig:/bin/bash
[root@z-sv-test samba]#


This is definitly a different behavior to samba up until 3.4.x, where idmapping just took the gidnumber attribute of the user (and not the primary windows group).
Comment 10 Daniel Zabel 2011-04-19 14:11:51 UTC
There seems to be another change in 3.5.x idmap, which breaks getent behavior:

'getent group' & 'getent passwd' --> only shows local groups and local users.

root@co5itis01:~ # getent passwd domainuser

--> shows correct entry for this domainuser.

root@co5itis01:~ # getent group domaingroup

--> shows also correct domaingroup info.

wbinfo resolves everything correctly.

Seems to be broken since 3.5.x.
Comment 11 Björn Jacke 2012-10-02 17:35:16 UTC
Michael: does comment 9 need to be documented or is this unintended behaviour?
Comment 12 Björn Jacke 2012-10-02 17:53:06 UTC
Michael, there is bug #8694, which is about the comment #9 case. I'll close this one, hope that's okay.