1 |
On 9 Aug 2008, at 14:52, Yoav Luft wrote: |
2 |
|
3 |
>> In an ideal world users should use their domain username & |
4 |
>> password to log on when they sit down at the Linux box. And they |
5 |
>> should be mounting the directories they need off the file server |
6 |
>> by (double-clicking on a drive icon on their KDE desktop if |
7 |
>> necessary and) using their same unique credentials (*not yours!*). |
8 |
>> If you want to fully implement this then it's not a two minute |
9 |
>> job; you shouldn't need much from the Windows IT admins except the |
10 |
>> name of the domain and perhaps the resolvable name of the domain |
11 |
>> master server - you should be able to test using your own domain |
12 |
>> \user:pass |
13 |
> |
14 |
> That is, actually, what I'm trying to achieve, but what is crucial |
15 |
> to the usability of the linux box is that each user (a would be |
16 |
> developer) would have access to his own files and the departments |
17 |
> files on the server without any knowledge of the working of Linux, |
18 |
> Samba, or others. It would be especially nice if logon names would |
19 |
> be taken from the server, and those relief users to manually add |
20 |
> and configure more users. |
21 |
> I can think on an awkward solution, making a script that sets up a |
22 |
> new user and assumes the user name is the same as the one in the |
23 |
> domain. But I am sure there is a cleaner, better solution, only |
24 |
> that I haven't found it yet. |
25 |
> So, I will sum up shortly what I want, starting from most important: |
26 |
> 1. Users will have access to the departments files without root |
27 |
> access with their own privileges rather then mine (achieved through |
28 |
> given sudo to mount, and putting it all in a script). |
29 |
> 2. Users will have access to their own personal files (achieved |
30 |
> through the same script. Not sure if it is run automatically when a |
31 |
> user logs on) |
32 |
> 3. Any user on the domain will be able to log on to the machine, |
33 |
> and have access to his files, will automatically authenticate |
34 |
> himself to network services, etc. |
35 |
|
36 |
http://www.google.com/search?q=authenticating+linux+users+against |
37 |
+windows+domain |
38 |
|
39 |
Sorry to say "read teh g0ggles, newb", but I'd need to read a number |
40 |
of these pages myself before I could say "you want to do it this way |
41 |
not that" or before I was even aware of the advantages & |
42 |
disadvantages of the different approaches. |
43 |
|
44 |
Mostly you shouldn't need much from the Windows admins. If you were |
45 |
to install XP Pro on a new PC and bring it into the office, all you'd |
46 |
need to do is right-click on my computer and change from "My |
47 |
Workgroup" to "My Domain" (or "BobsElectricals" or whatever) - the |
48 |
next time the machine starts you'll need to log on using your |
49 |
username:password on the domain. Likewise all you *should* need to |
50 |
add the Linux box to the domain is its name, and perhaps the |
51 |
hostname / ip address of the master domain server. |
52 |
|
53 |
The approach for mounting shares isn't obvious to me right now, but |
54 |
hopefully will become clear to you during the days that you spend |
55 |
setting the authentication up. On a Linux Samba box there is a |
56 |
special share called "homes" and mounting that seems to automatically |
57 |
use the ~ of the user authenticating; on Windows you can refer to % |
58 |
user%, although you probably can't combine these two methods |
59 |
directly. I don't use Linux on the desktop, but KDE or Gnome or |
60 |
whatever probably has a facility to run scripts upon logon; write a |
61 |
Bash script calling var=`whoami` ; mount \\domainserver\$var and put |
62 |
it in /etc/skel (or the KDE / Gnome equivalent). |
63 |
|
64 |
Stroller. |