this is what you have to do i Hate AD
here is the link to the whole page the part i put in is the quick and dirty fpr win2k3 server and SBS server
http://www.wlug.org.nz/ActiveDirectorySambai know this is a bit of work but to get samba working on AD this is what needs to be done
if some one else here has a faster way or a DEV know a faster way that would help
also remember with SME you have bto use the template system or the DB commands
------------------------------------------------------------------------------------------------------------------------
These are the absolute bare minimum steps to get your Samba server integrated as a member server in an AD controlled domain with Win2k3 as the DC.
1. ENSURE your samba box has an A record and associated PTR in DNS.
2. On your DC, disable signing: Run Domain Controller Policy tool and edit Account Policies -> Security Options -> Microsoft network client: Digitally sign communications (always) Set this to Disabled. Do the same in the Domain Policy tool. Note, you will need to reboot the server for this step, though it won't tell you to. Disable on your samba server as well with the following in smb.conf
Note (PvtJoker?): In my experience that wasn't needed, this tutorial concentrates on windows 2003, and works without disabling these options.
client signing = no
client use spnego = no
3. On your samba server, install kerberos5, and edit /etc/krb5.conf. It should contain:
[libdefaults]
default_realm = YOUR.ADS.DOMAIN
dns_lookup_kdc = false
dns_lookup_realm = false
[domain_realm]
.your.domain.name=YOUR.ADS.DOMAIN
your.domain.name=YOUR.ADS.DOMAIN
[realms]
YOUR.ADS.DOMAIN = {
default_domain = your.domain.name
kdc = IP.OF.THE.DC
}
4. Ensure smb.conf contains
realm = YOUR.ADS.DOMAIN
workgroup = YOUR
security = ADS
5. Get a ticket using kerberos: kinit administrator (enter the administrator password when prompted). The klist command should then list a ticket.
6. Join the domain using 'net ads join'. This should use the credentials in your kerberos ticket.
7. Set up winbind - ensure the following is in smb.conf
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum groups = yes
winbind enum users = yes
8. store your winbind credentials with wbinfo --set-auth-user=DOMAIN\\administrator%password
NOTE: This step may fail with one or more of the following errors:
could not obtain winbind separator!
could not obtain winbind domain name!
Should you receive either or both errors, it is because winbind is not currently running continue with the remaining steps and return to this step after winbind has been started.
9. modify /etc/pam.d/samba (on woody) or the appropriate pam file to add "sufficient" for auth and account using pam_winbind.so. These need to go BEFORE the pam_unix.so calls for samba. My /etc/pam.d/samba is as follows:
auth sufficient pam_winbind.so
auth required pam_unix.so nullok
account sufficient pam_winbind.so
account required pam_unix.so
session required pam_unix.so
password required pam_unix.so
10. Modify /etc/nsswitch.conf with the following:
passwd: winbind compat
group: winbind compat
shadow: winbind compat
11. Restart samba and winbind.
12. All should work.
Browse your server and see...
Samba and software deployment
Software deployment is a useful feature of a domain controller, as it allows to distribute software to many clients - and thus, the administrator doesn't have to walk from one workstation to another (10, 20, ... 100 machines...) to install the same piece of software (and uninstall it or upgrade a couple of days later).
One common misconception when comparing Samba to Active Directory, is that with Samba you can't deploy software to your Windows workstations. Another misconception, this time about Active Directory, is that with AD you can deploy software to your workstations. So, what's this all about?
Active Directory can only deploy packages in MSI format. This isn't very widely used; mostly software is available in EXE format.
With Samba, as in whole *NIX philosophy, one tool does the job, but does it well.
To distribute software with Samba, one can use WPKG - with this tool, you just configure the software which should be installed / upgraded / uninstalled on a given machine or a group of machines - and next time these Windows workstations are booted, the software you specified is installed / upgraded / uninstalled automatically.
Footnotes
1. %Systemroot% is a variable set by Windows NT and onward to mean "the location where Windows is installed", ie c:\winnt, c:\windows, etc.
13 Replies
4393 Views