[PATCHES] Add Unix attributes to a user or group

[Rowland Penny]

On Thu, 22 Sep 2016 08:36:53 -0500
Andrew Bartlett <abartlet at samba.org> wrote:

> On Thu, 2016-09-22 at 13:56 +0100, Rowland Penny wrote:
> > Hi, these patches allow RFC2307 attributes to be added to a user
> > or group created on ADUC.
> > 
> > The first patch for samdb.py actually does the addition/modification
> > 
> > The second & third patches will add the same attributes that windows
> > adds via the Unix Attributes tab in ADUC (note: this tab does not
> > exist
> > on win10).
> > 
> > the fourth patch allows adding or modifying user attributes, either
> > single or multiple attributes, these will be prompted for.
> 
> Thanks Rowland.  
> 
> I do very much appreciate your efforts to improve samba-tool.
> 
> As you have probably come to expect, my first request is to please
> write up the matching automated tests. 

I am quite prepared to update the 'samba-tool user create' test, but
only after the test is updated to actually test what samba-tool does
now when a user is created with rfc2307 attributes.
 
> 
> We need tests that run the various options (because python errors are
> only discovered when code is run, so we must cover all the codepaths),
> and we need tests that confirm that the values are correctly modified
> in the database by comparing with the results in the LDB entries.
> 
> Regarding 'nisadd', I'm assuming we are specifying the invalid
> unixUserPassword out of some caution that someone will foolishly use
> this for real NIS, and missing might become an empty password?  Can
> you check if this really happens? 

This was discussed when Marc altered 'samba-tool user create', this
is exactly what ADUC does.

> I also think we should avoid
> making more reference to NIS than we need to, it is old, outdated and
> no longer relevant to what we are doing, it just happens to be where
> some of the schema came from.  For that same reason, the --nis-domain
> option should be omitted, and if we must fill it in for the windows
> GUI, then we should just use our workgroup name or the value given
> for whole domain if that is stored somewhere (check how provision
> specifies it).

Just what do you think 'nis-domain' is ??? would it be better if I used
--NETBiosName or --workgroup or something else???


> 
> Given all that, I think we should make this just part of a generic
> 'user modify' that fills out any required parts for rfc2307 when those
> elements are specified, just like 'samba-tool user create'.  (I
> realise that --nis-domain is specified there, but I would like that
> removed in the long term).

It does exactly what samba-tool user create does when you add the
relevant RFC2307 attribute.

What are you going to replace --nis-domain with?? 
If you want, I can set --nis-domain automatically by sourcing it from
CN=<WORKGROUP>,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,DC=example,DC=com

> 
> For 'samba-tool user modaddrs' can you explain a little more what this
> brings over ldbedit?  I ask as the tool is restricted to ldap
> attribute names, does not show the existing values, and does not
> throw an error for invalid attribute names (it seems to just
> continue).

You and I may be comfortable using ldb tools to manage sam.ldb, but
others aren't. I understand this patch isn't perfect, but it is
somewhere to start from, if anybody has any ideas how to improve it, I
am very willing to listen.
 
> 
> Perhaps if you want to make it a friendly ldbedit, we should have it
> display the object in that tool, just avoiding the search expression
> steps?
>

> I realise this is a lot of criticism, and I'm asking for a significant
> amount more work, but we do need to take the time to get our user
> interfaces correct, as once released, we should avoid changing them.

OK, I will withdraw the last patch and try and make it more friendly,
but we need the the other three, or have you missed the fact that win10
no longer has the Unix Attribute tabs ?

I will repeat it again, these patches only do what the Unix attributes
tab does on ADUC.

> 
> Thanks,
> 
> Andrew Bartlett
>