[Samba] idmap & migration to rfc2307

[Jonathan Hunter]

Hi Rowland

On 14 June 2015 at 09:22, Rowland Penny <rowlandpenny at googlemail.com> wrote:
> I was trying to show that you do not need sssd to get consistent IDs, you
> just need to use the RFC2307 attributes. In fact you can use one or the
> other, you just shouldn't use both.
> sssd, as you have found, uses a long number to identify a domain object when
> in 'rid' mode, unlike samba that uses 'DOMAIN\IDNUMBER', it shouldn't matter
> which you use as long as you stick to just one.

Sorry, yes - understood. I would *prefer* to use the sssd mapping
method rather than specifying a rid mapping range as per samba, but I
understand that neither are appropriate in my case with samba at the
moment, so I need to use rfc2307 throughout instead - that's fine.

> Samba tries to discourage the use of a DC as a fileserver, one of the
> reasons being the problems you are having, you would not have these problems
> if you added a member server and used this for serving files. I also
> understand that this is easier said than done, in which case, you will have
> to work around any problems, as and when they occur.

Yep.

> It would seem that something is re-writing your winbind cache and this could
> be hard to track down. The first thing I would do is to turn off selinux,
> just in case this is the problem, though this usually manifests itself in
> not being allowed to do something, rather than doing something. I would then
> investigate if replication is working correctly, is AD the same on both DCs
> (you can use ldapcmp to do this). You should be aware that unless your users
> log into a DC, it doesn't really matter what ID number they have on that DC.

And this is, I believe, the interesting part. I think that something
inside samba winbindd is doing this, when I am using rfc2307 - it
doesn't do it now I have disabled winbindd and enabled winbind
instead. (I've taken the UNIX host itself out of the samba equation by
using sssd totally separately on that side). selinux is not enabled on
this server.

ldapcmp shows that LDAP is consistent, apart from the whenChanged
attribute which does slightly differ between DCs:

[root at dc1 ~]# samba-tool ldapcmp ldap://dc1 ldap://dc2 --filter=whenChanged

* Comparing [DOMAIN] context...

* Objects to be compared: 497

* Result for [DOMAIN]: SUCCESS

* Comparing [CONFIGURATION] context...

* Objects to be compared: 1634

* Result for [CONFIGURATION]: SUCCESS

* Comparing [SCHEMA] context...

* Objects to be compared: 1561

* Result for [SCHEMA]: SUCCESS

* Comparing [DNSDOMAIN] context...

* Objects to be compared: 102

* Result for [DNSDOMAIN]: SUCCESS

* Comparing [DNSFOREST] context...

* Objects to be compared: 23

* Result for [DNSFOREST]: SUCCESS


-- 
"If we knew what it was we were doing, it would not be called
research, would it?"
      - Albert Einstein