[Samba] ldbedit: no matching records - cannot edit (newly-created user)

[Jim Seymour]

On Thu, 10 Sep 2015 20:30:17 +0100
Rowland Penny <rowlandpenny241155 at gmail.com> wrote:

> On 10/09/15 20:06, Jim Seymour wrote:
> > On Thu, 10 Sep 2015 18:55:08 +0100
[snip]
> > Ho-ly smokes, what an incredibly clunky thing this Samba4 thing is.
> > It's as if the developers set out how to create MS-Win domain
> > support in a way that is as decoupled from, and as hostile to, *nix
> > as they possibly could.
> 
> Yes, it works just like a windows AD DC :-)

That's kind of scary, actually, and no mistake.  The stuff I've read
about AD, in trying to figure out how to do things... *shudder*...

> 
[snip]
> 
> >
> > (I'm trying to get roaming profiles going while waiting for answers
> > to this thread.  They don't work, either.)
> 
> Roaming profiles do work and I am sure others will back up this
> statement.

By "they don't work, either" I meant: Doing everything the docs say to
do has so far not resulted in working roaming profiles.

> 
[snip]
> If you have existing users and groups, you can user their existing 
> UID/GID numbers in AD, investigate the 'uidNumber' & 'gidNumber' 
> attributes in AD.

There certainly are existing users and groups.  About 100 users and
dozens of groups.  This is a living, breathing production LAN that's
been in existence for over 25 years.

> 
> >
> > A UID number of "3000024" is *way* outside the UID_MAX value for an
> > out-of-the-box Linux system.  (Ubuntu 14.04 LTS is 60000.)
> 
> Actually it is a 16bit number, so I suppose it will 65536, it must be 
> because 'nobody' is 65534 on debian.

$ grep UID_MAX /etc/login.defs
UID_MAX			60000

Not certain it's actually a 16-bit value, tho.  It's whatever UID_TYPE
is, which, on my Ubuntu boxen, evaluates to a __U32_TYPE, which
evaluates to an unsigned int, which is 32 bits.

> 
[snip]
> 
> All I can say is that it works if it is set up correctly, most of the 
> time when admins have problems with a samba4, it is usually because
> the admin is trying to 'bend' it do something it isn't capable of.

I've got a functional AD DC.  The only "bending" I've done, so far, is
I'm running it on what will be the file- and everything-else-server.
But the AD DC *is* in its own sub-domain and appears to be happy.

As for configuring users, clients, roaming profiles: I'm following the
docs *to the letter*.

> 
[snip]
> 
> It may help us to help you if you explained just what you need to do.

Very well...

We have an existing does-everything-server.  It's currently running
Samba3, built and installed from a tarball.  I'm building a replacement
server.  I had *hoped* to move us to an AD, as opposed to using simply
workgroups.

This machine *will* be the "does everything" server.  We will sacrifice
AD before that will change.

So, we have users.  Nearly a hundred real users and a few
"pseudo-users" (which aren't germane to this discussion).  We have
about 1TB of storage, approximately 70-80% of which is consumed.  We
have a bit over 100 desktops.

Currently users log in and can see a variety of network shares--some of
which any particular user can access to one-degree-or-another.  Others
they cannot.  This is currently controlled by Unix UID and GID, and
sometimes by Unix (POSIX) ACLs.

Each user also sees his or her \\Server\username share, automatically.

We require a high degree of interoperability between MS-Win desktops
and Unix/Linux logins, being as, while most of the end-users are purely
MS-Win point-and-click users, a not insignificant number are Linux/Unix
users.  (Some network shares will also be shared-out to some clients via
NFS, tho it's unlikely I'll wade into Linux' disastrous automounter.)
Linux/Unix users also typically occasionally use MS-Win.

What we had *hoped* to end up with is essentially what we have, but
with domain logins for the MS-Win desktops and laptops--rather than
individual machine accounts, and roaming profiles--so that when a user
went to use a different machine, all their settings would be there
automatically. It would be nice to eliminate the need for hand-creating
user accounts on every PC, and, in the few cases where everybody in a
department must be able to use any PC in the department: Having to do
so multiple times.

I am *strongly* desirous of not having to use MS-Win to administer this
server. I don't currently use MS-Win.  I don't like MS-Win (and that's
putting it mildly). I don't plan to use MS-Win.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.