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.
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.
[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.
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.
Sean Parsons
-----Original Message-----
From:
plug-discuss-bounces@lists.plug.phoenix.az.us
[
mailto:plug-discuss-bounces@lists.plug.phoenix.az.us] On Behalf Of Craig
White
Sent: Sunday, January 31, 2010 6:48 PM
To: Main PLUG discussion list
Subject: RE: Looking for a mentor/adviser
On Sat, 2010-01-30 at 17:49 -0700, Sean Parsons wrote:
> Craig,
> I don't doubt that people do it. I made several honest attempts to
> research, understand and implement a Samba file server in and existing
Small
> Business Server 2003 network using LDAP and Kerberos. I was not able to
make
> it work, so I changed my plan and I asked if someone was willing to mentor
> me through another try. Since I didn't need multiple opinions, I just need
> to discover what I did wrong/what works, I wanted to avoid a large forum,
> and I'm sorry if that seems to keep upsetting people.
>
> Here's What happened:
>
> The How tos were really vague for adding Samba to anything but the
> simplest windows network (NT4), Then most examples assumed I was building
a
> standalone server with the same functionality, not adding one. Based on my
> research it looked like the process was straight forward and so I built a
> Ubuntu server (LAMPS) and I set out to join it to my domain.
----
vague? seriously? Samba has the best free documentation of any open
source project.
The Official Samba HowTo & Samba By Example both are available at
www.samba.org (linked on the main page). The HowTo is exhaustive
documentation developed over many years and the 'By Example' gives you a
complete walk through on many various scenarios of usage.
Using any other documentation is just stupid.
----
>
> I knew I needed LDAP and Kerberos so I tried to set those up with
> Webmin, they attempted to alter my existing domain controller and things
> went horribly wrong. I recovered my DC from backup and tried it a second
> time using the CLI, but I was not able to find where settings were stored
> and again, I tried to use the example files from Samba.org as a model, not
> knowing what is needed or not, may have contributed to a second failure.
> Again I recovered my Server form backup and changed tactics.
----
you don't need LDAP to join a Linux server to AD. You have bad
information. Neither LDAP nor kerberos have any ability to 'alter' an AD
controller. Bad information and bad conclusion.
----
>
> I then tried to join a linux workstation to the domain with "like
> wise" and it worked, sort of. Small Business Server isn't just Windows
> Server 2003 with a new name. It adds Exchange and SQL has other scripted
> functionality embedded into AD which is why you have to use it's wizards
for
> everything. After joining I started to have problems as AD was not
properly
> formatted when the workstation was joined. SBS uses the AD tables for more
> than just domain membership, we have exchange, etc that rely on it. So Yes
> it probably can be done, but it is not simple, nor is it intuitive, it is
> specific to the type of environment. My AD environment isn't broken, it
> required specific settings that couldn't be anticipated from the how to
and
> guides I found on Samba.org.
----
Again - Linux servers and workstations are joined to AD domains all over
the world without 'breaking' anything and I am quite aware of what SBS
is and Windows networking.
----
>
> I asked in IRC #Samba, #ubuntu-server, #Ubuntu-us-az, and #plugaz
> several times for help to understand where I went wrong and nobody
answered,
> or if they did, I was told "Oh that is really tricky and I never did
> it"..... Samba's documentation admits issues with non NT4 AD
implementation
> and promises to fix it in V4, but I wanted to talk to someone who had done
> it and nobody answered.
----
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.
I think your statement 'Samba's documentation admits issues with non NT4
AD implementation and promises to fix it in V4' is completely flawed.
Craig
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)