[Samba] Internal DNS logging

[mathias dufresne]

2015-11-05 11:17 GMT+01:00 Rowland Penny <rowlandpenny241155 at gmail.com>:

> On 05/11/15 09:55, mathias dufresne wrote:
>
>> Code is like books, or art (painting...). Some guy produce something, as
>> he
>> likes, some others use/watch/listen it, as they like. Most of the time
>> these two ways are different.
>>
>> What I mean is it is not because something was not developed to be used in
>> some way that way of usage is not a good way of usage.
>>
>> Perhaps for most of us this is not the right way the OP want to do. Anyway
>> it is his way. Who are we to tell what he's doing should not be? I thought
>> opensource was more open than the other world.
>>
>
> Samba4 initially used the bind9 flat files way of running, but it didn't
> and couldn't be made to work as an AD DC expects. This is why Samba4 moved
> to dlz, a lot needed to be done to get this to work, but it does work as
> expected, ok there are a few minor problems, but I am sure these will be
> fixed in time. I am not saying that the OP cannot use flat-files, just that
> he is on his own there.


I didn't write against your previous mail but more generally against a way
of mind I don't like. Software are tools and what users do with tools is
under their own responsibility. And sometimes, some user find a way of
usage which was not foreseen by anyone, and rarely that new way of usage is
a really good idea.
I don't mean my ideas are better than those from others ;)


>
>
>
>> Same thing but about SSSD: I was thinking providing to my client same
>> behaviour for Linux systems as on Windows systems about local
>> administrators of computers (clients). On Windows you can define groups
>> and
>> using GPO put some group(s) in client's local "administrators" group.
>> There
>> you have people able to manage clients systems without any rights on AD.
>> This can be done using LDAP tree and user accounts with UID = 0. SSSD
>> comes
>> also with filters to avoid peoples with UID=0 which have no right to
>> connect on some systems can connect on these refused systems.
>> So I had all I wanted to give my client same way of managing all their
>> systems with nominative accounts, to be able to trace a little bit what
>> admins do.
>> This is not possible because SSSD refuses (hardcoded...) users with UID=0
>> to connect on SSSD systems. I was told this is for security reason: SSSD
>> through LDAP can, under certain configuration, grant man in the middle
>> attack (or something like that).
>> The fact is using AD servers are also authenticated, this security reason
>> disappear. Not the refusal because devs think what they thought is the
>> only
>> to think. I don't.
>>
>
> That is (in my opinion) a stupid way of doing things, every user with the
> UID of 0 raises the potential for an attack, if you want to do this, use
> sudo instead and yes sssd, AD and sudo will play nicely together.
>

Perhaps you think it is, anyway that's how IT world is proceeding for users
for computer management as soon as we speak of computers, and they are
numerous, and they work not too badly. I'm not confident enough in my own
knowledge to say all Windows world is stupid.

Now you speak about sudo and it is a very great tool if you don't have to
much things to delegate. Once you want to give full access to one server to
someone because that one is a sysadmin, sudo become a bit complex if you
want to trace stuffs (refusing shells, even in vi/awk... and still give
this user a way to work quickly, efficiently). This is true because I take
as a reference my own knowledge or more exactly my own lacks of knowledge.


>
> Just because you think something is a good idea doesn't mean it is, but
> nobody is stopping *you* doing things your way, just don't expect sympathy
> if things go wrong.


Oh I'm not much loving myself to think that :D
And I grown old enough to fully understand that using a tool for something
it is not initially meant for, support goes away, thank you.

Cheers,

mathias


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