samba - Apr 2015 - How can I have new users/groups to include posixAccount/posixGroup schema automatically?

Greetings, Rowland Penny!
>>>>> well tough, the smbldap-tools were written to do a job, map
windows
>>>>> users to unix users and vice versa.
>>>> No. smbldap-tools were doing exactly the same as AD do: kept
all users in one
>>>> database.
>>>>
>>> Similar, but not the same, with smbldap-tools you had Unix and ldap
>>> users,
>> If you want to put it that way...
>>
>>> with Samba4 AD,
>> ...I have Unix and AD users.
>>
>>> just like windows AD, you just have AD users.
>> No.
> Lets put it this way, you cannot have a local Unix user and an AD user 
> with the same name.
That is true for LDAP users as well. When LDAP available, it always overshadow
my local account with LDAP one.
>>>>> So what you need now is something to do the same, except
you don't have
>>>>> separate Unix users any more,
>>>> I never had separate unix users ever (aside from one user -
myself, but that
>>>> was more of a requirement of OS installation process).
>>>>
>>>>> just users in AD who can also be Unix users.
>>>>> If you want your Unix users to have the same IDs
everywhere, you need to
>>>>> use the RFC2307 attributes,
>>>> Already.
>>>>
>>>>> at the moment, how the attributes get into AD is up to you,
use ADUC,
>>>> Time-consuming, requires available Win7 machine. In short - not
an option.
>>>>
>>>>> samba-tool
>>>> Doesn't work, as evidently demonstrated recently in the
list.
>>>>
>>>>> or write your own scripts.
>>>> The problem with any homemade script is that it isn't
portable, and only go as
>>>> far, as the script writer's understanding of the things at
hand.
>>>> My personal understanding of the AD schema is very limited. I
could throw
>>>> something together, but in reality, I'd rather not do
anything like that
>>>> myself.
>>>>
>>>> All that being said, I see the situation as very disturbing.
The lack of the
>>>> very basic, essential tools to manage user/group creation...
I'm speechless.
>>>>
>>>>
>>> The user tools are there, they are mostly on windows though.
>> Can you list some of them?
>> RSAT is not an option - the only Win7 Pro system at work is a render
farm that
>> have its own work to do, than to let me twitch the checkboxes in some
>> overloaded GUI.
>>
>>
> If you only have access to one windows domain machine, why are you 
> running an AD domain, you would probably be better of running NFS
I have six Windows machines that I'm responsible for. Only one of them is
Win7.
There's other machines (personal notebooks that are not part of the domain),
that are using SSH/VPN/CIFS access to the servers.
> I am coming to believe that you want everything handing to you on plate, 
> i.e. you don't really want to help yourself, you want everybody to do 
> your work for you.
I've already "helped myself" in the past three months. That's
a big chunk of
life taken away by something that should have been a relatively simple
process.
All I want now is a working system that would not require my everyday
attention for the next seven years.
Is this too much to ask for?


-- 
With best regards,
Andrey Repin
Friday, April 10, 2015 00:24:50

Sorry for my terrible english...

On 09/04/15 22:33, Andrey Repin wrote:
> Greetings, Rowland Penny!
>
>>>>>> well tough, the smbldap-tools were written to do a job,
map windows
>>>>>> users to unix users and vice versa.
>>>>> No. smbldap-tools were doing exactly the same as AD do:
kept all users in one
>>>>> database.
>>>>>
>>>> Similar, but not the same, with smbldap-tools you had Unix and
ldap
>>>> users,
>>> If you want to put it that way...
>>>
>>>> with Samba4 AD,
>>> ...I have Unix and AD users.
>>>
>>>> just like windows AD, you just have AD users.
>>> No.
>> Lets put it this way, you cannot have a local Unix user and an AD user
>> with the same name.
> That is true for LDAP users as well. When LDAP available, it always
overshadow
> my local account with LDAP one.
This is one area you need to read up on, whilst with LDAP you can have a 
user called 'joe' in /etc/passwd and LDAP, you cannot do this with AD, 
your users must be either in /etc/passwd or AD, but not in both.

Rowland
>
>>>>>> So what you need now is something to do the same,
except you don't have
>>>>>> separate Unix users any more,
>>>>> I never had separate unix users ever (aside from one user -
myself, but that
>>>>> was more of a requirement of OS installation process).
>>>>>
>>>>>> just users in AD who can also be Unix users.
>>>>>> If you want your Unix users to have the same IDs
everywhere, you need to
>>>>>> use the RFC2307 attributes,
>>>>> Already.
>>>>>
>>>>>> at the moment, how the attributes get into AD is up to
you, use ADUC,
>>>>> Time-consuming, requires available Win7 machine. In short -
not an option.
>>>>>
>>>>>> samba-tool
>>>>> Doesn't work, as evidently demonstrated recently in the
list.
>>>>>
>>>>>> or write your own scripts.
>>>>> The problem with any homemade script is that it isn't
portable, and only go as
>>>>> far, as the script writer's understanding of the things
at hand.
>>>>> My personal understanding of the AD schema is very limited.
I could throw
>>>>> something together, but in reality, I'd rather not do
anything like that
>>>>> myself.
>>>>>
>>>>> All that being said, I see the situation as very
disturbing. The lack of the
>>>>> very basic, essential tools to manage user/group
creation... I'm speechless.
>>>>>
>>>>>
>>>> The user tools are there, they are mostly on windows though.
>>> Can you list some of them?
>>> RSAT is not an option - the only Win7 Pro system at work is a
render farm that
>>> have its own work to do, than to let me twitch the checkboxes in
some
>>> overloaded GUI.
>>>
>>>
>> If you only have access to one windows domain machine, why are you
>> running an AD domain, you would probably be better of running NFS
> I have six Windows machines that I'm responsible for. Only one of them
is Win7.
> There's other machines (personal notebooks that are not part of the
domain),
> that are using SSH/VPN/CIFS access to the servers.
>
>> I am coming to believe that you want everything handing to you on
plate,
>> i.e. you don't really want to help yourself, you want everybody to
do
>> your work for you.
> I've already "helped myself" in the past three months.
That's a big chunk of
> life taken away by something that should have been a relatively simple
> process.
> All I want now is a working system that would not require my everyday
> attention for the next seven years.
> Is this too much to ask for?
>
>

El 10/04/15 a les 09:21, Rowland Penny ha escrit:
>> That is true for LDAP users as well. When LDAP available, it always
>> overshadow
>> my local account with LDAP one.
> 
> This is one area you need to read up on, whilst with LDAP you can have a
> user called 'joe' in /etc/passwd and LDAP, you cannot do this with
AD,
> your users must be either in /etc/passwd or AD, but not in both.
In my limited testing I see no difference between the previous setup
(samba3+openldap+nss-ldap) and the testing one (samba4+winbind), where I
have my personal user both in /etc/passwd and in AD.
I can login, my id shows correctly and group membership is the
combination between the one in /etc/group and the one coming from AD.

Bye
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es
Tel. +34 935883004  Fax +34 935883007

Greetings, Rowland Penny!
>>>>>>> well tough, the smbldap-tools were written to do a
job, map windows
>>>>>>> users to unix users and vice versa.
>>>>>> No. smbldap-tools were doing exactly the same as AD do:
kept all users in one
>>>>>> database.
>>>>>>
>>>>> Similar, but not the same, with smbldap-tools you had Unix
and ldap
>>>>> users,
>>>> If you want to put it that way...
>>>>
>>>>> with Samba4 AD,
>>>> ...I have Unix and AD users.
>>>>
>>>>> just like windows AD, you just have AD users.
>>>> No.
>>> Lets put it this way, you cannot have a local Unix user and an AD
user
>>> with the same name.
>> That is true for LDAP users as well. When LDAP available, it always
overshadow
>> my local account with LDAP one.
> This is one area you need to read up on, whilst with LDAP you can have a 
> user called 'joe' in /etc/passwd and LDAP, you cannot do this with
AD,
> your users must be either in /etc/passwd or AD, but not in both.
$ id
uid=1000(anrdaemon) gid=1000(anrdaemon)
groups=1000(anrdaemon),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),114(lpadmin),118(sambashare),120(admin),512(domain
admins),513(domain users)

Practice >>> Theory
>>>>> The user tools are there, they are mostly on windows
though.
>>>> Can you list some of them?
>>>> RSAT is not an option - the only Win7 Pro system at work is a
render farm that
>>>> have its own work to do, than to let me twitch the checkboxes
in some
>>>> overloaded GUI.
So, what about tools?
Do you really know any, or just throwing ideas to the wind?
>>> If you only have access to one windows domain machine, why are you
>>> running an AD domain, you would probably be better of running NFS
>> I have six Windows machines that I'm responsible for. Only one of
them is Win7.
>> There's other machines (personal notebooks that are not part of the
domain),
>> that are using SSH/VPN/CIFS access to the servers.
>>
>>> I am coming to believe that you want everything handing to you on
plate,
>>> i.e. you don't really want to help yourself, you want everybody
to do
>>> your work for you.
>> I've already "helped myself" in the past three months.
That's a big chunk of
>> life taken away by something that should have been a relatively simple
>> process.
>> All I want now is a working system that would not require my everyday
>> attention for the next seven years.
>> Is this too much to ask for?
>>
>>


-- 
With best regards,
Andrey Repin
Friday, April 10, 2015 15:23:25

Sorry for my terrible english...