RE: Looking for a mentor/adviser

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Sean Parsons
Date:  
To: 'Main PLUG discussion list'
Subject: RE: Looking for a mentor/adviser
Craig,
    You are the master, and I'm just an idiot with 20 years of Microsoft
experience..... so you win, I'm totally wrong. 


I got nothing more to add, and no desire for this to continue to escalate.
Thanks for your time, and best wishes for the future.

Sean Parsons


-----Original Message-----
From:
[mailto:plug-discuss-bounces@lists.plug.phoenix.az.us] On Behalf Of Craig
White
Sent: Sunday, January 31, 2010 8:42 PM
To: Main PLUG discussion list
Subject: RE: Looking for a mentor/adviser

On Sun, 2010-01-31 at 19:49 -0700, Sean Parsons wrote:
> Craig,
>
>     We obviously don't agree. I followed those examples and they didn't
> work. They were not easy to follow nor did they make the process easy to
> understand, perhaps you are using your experience to draw from, which I
> don't have. You also say I didn't need LDAP or Kerberos, that's pretty
> arrogant when you didn't know why I selected them in the first place, yes

it
> may be possible to make it work without them, but my decision was to use
> these components and that's when everything went wrong. You are free to

sing
> the praises of Samba, maybe someday I will to. But for know I know I can't
> do it from the documentation and I needed help. My statements stand as

facts
> from my experience, and you were not there, nor have you considered my
> explanation beyond defending your opinion, which is not right or wrong,

it's
> your opinion.

----
You have a serious language comprehension problem.

I clearly said you didn't need LDAP to join Samba systems to AD. I did
not say you didn't need kerberos to join Samba systems to AD because you
do.

I am hoping that you take more time to comprehend what I am saying
because I am being very precise.

The only praise I sang for Samba was their documentation because it is
incredibly complete. Most people do not want to comprehend that much
information and so they go elsewhere for less information.

The problem is that there are so many different scenarios for using
Samba, both as a server and as a client. It can be a domain controller
or a domain member, it can be a client or server using Windows 98 File
sharing methods or current CIFS methods. It supports ancient and current
Windows authentication methods (again both as client or server). It can
configure into local system authentication/authorization using many
different mechanisms including /etc/passwd, LDAP and AD. It provides
support for Windows printing both as server and as client. In short,
there is so much that Samba does that no simple documentation could
possibly exist.

But more to the issue... I have used Samba for over 10 years, have used
it in all possible ways and NEVER have I ever seen or even heard of a
reliable report that 'joining' a system to AD has damaged the AD setup.

And yes, we clearly disagree but I actually employ Samba at various
levels in various businesses and have no issues with using it and
somehow have managed to do this without damaging AD domain controllers.
----
>
> I needed LDAP and Kerberos to handle the users and credentials, you may

have
> decided not to integrate user accounts, but for me it was essential and I
> have no idea how you would do that without LDAP. I use Kerberos for my
> windows network, so it stands to reason I would use it on this Samba

server
> residing in my network, heck it's even in the manual. I stated in my
> explanation where it went wrong, deciding that I'm wrong by doing it
> differently is not the same thing. I have a Linux based firewall that uses
> LDAP to authenticate users for access, works like a charm, so I've had

some
> experience. My users should not have to re-authenticate every time they
> access a file, and caching credentials separately means I have to change
> them every time somebody changes a password, so I think you over

simplified
> the problem. What I did wrong was not knowing what I was doing with Samba
> and trying to do this on a production network, because I thought I
> understood what I was doing.

----
You still haven't provided any reason to use LDAP. Samba and any
reasonable Linux distribution can surely use the account information
provided by AD.

So far, the only problem I think I over simplified is thinking that you
actually understand Windows networking because it seems pretty clear
that you are hoping for Linux walk-throughs and and Webmin to conceal
the problem that you don't understand Linux.

Just so we're clear... Windows SBS server is essentially a crippled
Windows Server that I presume they sell so small businesses everywhere
don't use Linux servers.
----
>
> [Samba 3.x cannot participate as a domain controller on an AD domain.]
> [Documentation is quite clear. But it is relatively simple and benign for]
> [it to join an AD domain as a member server/workstation. It works, it's]
> [relatively simple and it is not hazardous to an AD domain whatsoever.]
>
> Chapter 4 of the Samba documentation states multiple times the need to

LDAP
> to function completely, it does say it can work without - but at a loss of
> functionality, i.e. Single Sign On (SSO). It also talks about it's ability
> to work with NT4, but shows some caveats in 200x AD without additional
> components, and several warnings about potential problems with
> configuration, So I can point to where my information came from, and why I
> chose to use the elements. I remember now that the use of Winbind was also
> part of the process with LDAP so that should also be an element into my
> failure.

----
I'm quite sure that you are confusing various bits of information here
because you don't need LDAP running on any Linux system for it to
'function completely' as an AD domain member. LDAP is part of AD but you
do not need to run another LDAP server on Linux to 'join' AD as a domain
member.

I absolutely defy you find somewhere in the documentation that says
otherwise.
----
> Chapter 4 - "Domain Controller Types" and "Preparing for Domain Control"
> explain that it CAN function as a domain controller, and how. You may want
> to visit that section, and see where I got my information.
>
> I followed the documentation as best I could with the information I had,

and
> it didn't work. If you can make it work differently, bravo! You are a

better
> man than I, but then I already admitted I couldn't do it.
>
> [I think your statement 'Samba's documentation admits issues with non NT4]
> [AD implementation and promises to fix it in V4' is completely flawed.]
>
> I request you go to samba.org, click Latest News, and read the entry for
> December 25, 2009. Covers the added functionality promised in V4, so I
> believe I accurately paraphrased that article. Chapter 4 speaks volumes
> about limits and potential issues with implementation and the need for
> specific planning to minimize or avoid these issues.

----
Samba 4 has nothing to do with Samba 3.x which is the only version of
Samba that any distribution will use at this point. It is the only thing
that I am discussing with you. It is new, rewritten, at best at an alpha
level and intended to provide full AD functionality as any part of an AD
forest. That of course has nothing to do with the conversation that we
were having.

Craig


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss