Hi Michael,

Thank you for your hard work. Can you hazard a guess at what might be causing winbind to not automatically create mappings in the ldap backend?

Also, can one make winbind direct that kerberos authentication be used?

In 3.0.33, kerberos was used but in 3.5.4 which I am currently running, ntlmv2 is being chosen and that is problematic as workstations are NOT being checked against winbind but against samba.

cheers,

Christopher

On Wednesday, December 01, 2010 12:40 AM, Michael Adam wrote:
Hi Christopher,

thank you for your comments.

I know that idmap configuration has been a pain to get and keep
right over the releases. This is a pity. One of the aims, I have
been pursuing with my latest rewrite is to make ID mapping
config slightly simpler, while staying mostly backward
compatible. I am convinced that the removal of the alloc config
will get us rid of a continuous source of grief and confusion.
And I will of course do my best do document things as good as
possible. Please bear with me and carefully check config vs.
documentation once 3.6 is out. And please report bugs if there
are inconsistencies. Also please insist if I don't react in a
timely manner. If I loose track due to being busy with other
topics, I am thankful for any reminder to fix my bugs... :-)

Cheers - Michael


Christopher Chan wrote:
Hi Michael,

I, for one, am using config alloc because that is how things were done
on 3.0.xx before I migrated data to a new box that uses 3.5.4. I do not
care very much about the configuration changes. But I beg you that
documentation regarding idmap_ldap is updated including how idmap_ldap
works.

I had issues getting the configuration in 3.5.x to a state where I could
run wbinfo --set-* successfully and I still have an outstanding issue
where new accounts created in AD are not being automatically mapped by
winbind and I have to manually create these mappings.


In my idmap rewrite, I kept the alloc related parameters for the
LDAP idmap backend for now:

- idmap alloc config : ldap_url
- idmap alloc config : ldap_base_dn
- idmap alloc config : ldap_user_dn

and the related idmap alloc secret.

I would like to get rid of these.

Be my guest. I don't care so long as these changes are documented so
that people will know what is going on. This will be the second time
that I will have had to fight with changes in idmap ldap related
configuration without notice.



Therefore, I am asking here, if there is
anyone out there using these?
I can not imagine a reason why one would
want to use different server and/or user+password
for storing the uid/gid counter.

Right now there is nothing that actually explains to me what idmap_ldap
does and so I don't have a clue as to what are you talking about.



The only option that I would attest a certain, though minimal,
right to exist is the ldap_base_dn. But usually, it should
imho ok to store the uid/gid counter in the same location
as the mappings.

So, again: Are these options needed/used at all?

There is an awful lot of 'documentation' out there detailing the use of
alloc. People go nuts just figuring out how to do winbind + ldap.


Or can I remove them for 3.6.0 ?

Be my guest! Just update/provide documentation!



Cheers - Michael


Note: If we need to keep any of the options, the current form
(idmap alloc config :<option>   = ...) would reference
the default config, but my idmap rewrite would enable us
to set these on a per-domain basis, which would call
for options like this "idmap config DOMAIN : alloc_<option>")




----- End forwarded message -----



--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Reply via email to