[NTLUG:Discuss] Asking the right Questions (Samba + AD)

Chris Cox cjcox at acm.org
Tue May 8 14:27:14 CDT 2007


. Daniel wrote:
> Chris, you *ARE* the man.
> 
> Okay, so your few bits of advice either helped directly or pointed me in 
> the correct directions and for that I'm grateful.

If you're up for it, I can give you a login on our website (pmwiki) and
you can create a writeup there.

Let me know...

> 
> If anyone is interested in my findings, I'd be happy to answer questions 
> about what I had learned, but I will say that one guide I stumbled upon 
> definitely gave me all the details and explanations I needed to make it all 
> come together in a way that I felt I came away actually learning something 
> in the process.
> 
> http://www.infosecwriters.com/text_resources/pdf/AD_and_Linux_TMunn.pdf
> 
> The PDF indicated above is probably the best guide to accomplishing what I 
> wanted ever.  It also links to the sources the author used when creating 
> the guide.  It explains all the little settings you need and why.  That was 
> the important thing.  One thing I wish it mentioned was that the Microsoft 
> environment is slow when it comes to propagating status and information 
> across the network.  So when I tweaked this, that or the other and no 
> results came of it, I was left scratching my head wondering where I messed 
> up.  
> 
> So the first key point is to be PATIENT.  When you make some kind of change 
> with reference to the Active Directory Domain, it would be helpful if you 
> went off and did something else for about 5 minutes.
> 
> The next thing I learned from this guide that wasn't in any other guide was 
> the settings in /etc/nsswitch.conf.  All the guides I had seen before 
> discussed only passwd, shadow and group being linked to "files" and 
> "winbind" but made no mention of protocols, services, netgroup or 
> automount.  I don't actually know if that made a huge difference or not 
> (though I suspect it did make some when it came to getting groups 
> information into other apps like webmin's samba config app) but I included 
> the information from the guide as given and it worked in ways that I hadn't 
> seen before.
> 
> For another thing, mention was made about NTP... network time protocol or 
> whatever... and its significance in getting Kerberos to working properly.  
> That wasn't new information and it didn't provide anything specific other 
> than to say that the time info should be pulled from the domain servers.  I 
> didn't have to change anything from what I already had, but it was an 
> important checkpoint to verify that both machines were in sync.
> 
> The Kerberos configuration was quite a bit more detailed than others I had 
> noticed in the previous attempts.  I had no linkage to [appdefaults] or 
> [kdc] information.  It was also interesting that the documentation spelled 
> out that in the [domain_realm] section, the ".domain-name.com = 
> DOMAIN-NAME.COM" should come before the "domain-name.com = DOMAIN-NAME.COM" 
> line.  It stressed that this was critically important for some reason.  I 
> had both lines in there, but in the opposite order and that may have been 
> one of the reasons for the failures I was experiencing.  I also added an 
> extra line pointing to a second domain controller for kerberos information.
> 
> Finally, and probably most significantly, I added content lines as 
> specified related to PAM configuration.  Notably, it added usage of 
> Kerberos authentication modules.  (Also, it added the thing Chris mentioned 
> about mkhomedir.so... very useful)  I believe those additions were the most 
> significant aspects enabling the functionality I sought.
> 
> All in all, this guide provides an excellent checklist of points when 
> setting up a Samba Linux server in an active directory environment.
> 
> Now as far as all that ACL stuff goes; while I feel I could have done it 
> that way, I needed to remind myself that it was far and away from the 
> actual intent of this particular server.  In this case, it was so that 
> members of AD group "WebAdmins" and/or "WebDevelopers" would have 
> permission to log in and manage files for the company's intranet.  So I 
> sort of took a short-cut to that end.  I set the group permissions for the 
> share to reflect the requirement for group membership, but additionally, I 
> forced user (force user = and force group =) and group information to be 
> "apache."  ACLs are a moot point when using this approach and it works 
> exactly the way I want it to work under this scenario.  But if I were 
> creating a general purpose file server, then of course I would have gone 
> through the trouble of setting up ACLs and all that.
> 
> Once again, if anyone would like me to include my current config files or 
> anything else, I'd be happy to share the knowledge.  But I'll say that the 
> vast majority of anything I have is also mentioned in the guide indicated 
> at the top of this message.  It's VERY useful... very useful.
> 
> 
>> . Daniel wrote:
>>> Excellent!  That'll fill in the missing bits on login! :)  Great!  I'll 
> try
>>> that in the morning.
>>>
>>> Next, what if I want to share something like, say, /var/www/html to be
>>> writeable by members of the ADOMAIN\WebAdministrators group?
>> If you really have taken things all the way.. your files are now
>> under the auspices of POSIX (draft) ACLs.  The best way to change
>> the permissions is to have the owner (the web user) be an AD
>> user and change the permissions via Windows.
>>
>> If that's not what you want... you can at least play with settings
>> under Windows for some other directory and look at how it translated
>> into extended ACLs and manipulate the values from a linux shell.
>>
>>> Logs also show a problem with kerberos tickets... I'll search around 
> some
>>> more on that though... seems to be a common problem with few answers.
>>> (That is to say searching google for the error messages in the logs 
> yields
>>> many hits, but I have yet to find any answers associated with the
>>> questions.)
>>>
>>>
>>>> From: Chris Cox <cjcox at acm.org>
>>>> . Daniel wrote:
>>>>> Things seem to be working.  I just can't get to something useable.
>>>>>
>>>>> I can get user accounts to log in via ssh, for example.  I can ssh 
> into
>>> the
>>>>> box, using the format: ADOMAIN\username and it works except that
>>> there's no
>>>>> homedir created or anything like that... heck, I even tried logging
>>> into X
>>>>> using AD credentials.  It "tried" but since there was no home
>>> directory, it
>>>>> didn't happen.  Pretty neat really.
>>>> You can use root preexec = on the homes share to force creation of a
>>>> home dir for users hitting that share on the net.
>>>>
>>>> On the login side, use the pam module pam_mkhomedir.so
>>>>
>>>>> So here's the thing:
>>>>>
>>>>> How do I create a share that AD users can access?
>>>>>
>>> _________________________________________________________________
>>> ウェブページを印刷しても途切れない!便利なブラウザを使おう
>>> http://promotion.msn.co.jp/ie7/
>>>
>>>
>>> _______________________________________________
>>> http://www.ntlug.org/mailman/listinfo/discuss
>>>
>>>
>>
>> _______________________________________________
>> http://www.ntlug.org/mailman/listinfo/discuss
> 
> _________________________________________________________________
> MSNトラベルのクチコミ写真コンテストに参加してプレゼントをGETしよう! 
> http://special.msn.co.jp/travel/campaign/0410/index.htm 
> 
> 
> _______________________________________________
> http://www.ntlug.org/mailman/listinfo/discuss
> 
> 




More information about the Discuss mailing list