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