Nicolas Williams wrote:
>
> I'm glad I asked :)
>
>   
Me too. :)

> OK then the prescription is:
>
>  - setup a Unix nameservice for the Solaris and Linux systems
>
>     - AD SFU *will* do if you can get Linux's nss_ldap to use it (I'm
>       sure you can).  And AD SFU *will* make admistration easier for
>       you.
>
>  - setup either directory-based name mapping or name-based mapping rules
>    for the Solaris file servers.
>
>  - Make sure that for every Windows user and group that will be
>    referenced by the Windows clients (when talking CIFS to the Solaris
>    servers) there exists a user and group in the Unix nameservice and
>    corresponding mappings.
>
>     - Keep in mind that Windows groups can own files, so you may need to
>       ensure that each Windows group (and even users) maps to a Unix
>       user and a Unix group.
>
>   
I think this is becoming clearer. I was thinking that SID's needed to be 
converted to UID/GID's at login time also or Linux and S10 wouldn't get 
put the right UID/GID in the NFS operations. But really UID's and GID's 
are just looked up normally by username at login time, SID's are only 
mapped to UID/GID's when CIFS operations come into the Server.

So I need a NameService. Either my own (NIS, NIS+, or LDAP) where I 
manage accounts and mappings, or a SFU/AD setup and run by IT here they 
manage accounts and mappings?

If I choose my own NameService, then all I need for NFS between Linux, 
S10, and Nevada is for all of those to use it for username/passord 
lookups at login time, and The mappings only come into play when Windows 
clients connect to the Nevada Servers. The upside here is that I have to 
run a NameService eitherway if I want to manage the AutoMount, and other 
tables  myself. The only down side is I end up creating accounts for all 
employees in my  NameService and dealing ith password issues (lost, 
can't change, etc.) -- Unless I continue to 'steal' IT's  NIS password 
and group maps, or.... Is it possible to setup my own LDAP server with 
the Mapping, AutoMount, and other Unix 'Tables', but which proxies or 
refers LDAP clients to the AD server for Password and Group info? or 
will that require SFU also?

On the other hand if I can get SFU installed by IT, then all the Linux, 
S10, and Nevada machines can do lookups to SFU/AD (through LDAP? Is that 
the only choice?) to handle Logins, and the Nevada Servers will beable 
to also look up mappings for the Windows clients that connect? Upside 
here is IT add's new user accounts, and deals with password problems. 
Down side is they might not be willing to install it.

>> I just don't want to be in the bussiness of creating and managing user 
>> accounts. Today, the IT dept has several separate user databases, that 
>> they create accounts for new employees in when they join the company. 
>>     
>
> As long as you intend to use NFSv3 you have little choice.
>
>   
I don't mind managing a mapping table (though I'd rather not.) It's 
dealing with lost passwords, problems changing passwords, locked 
accounts, etc. I'd rather not have to deal with.

How is it that NFSv3 makes this a requirement?

> Make sure that your Linux and Solaris clients can use Kerberos to
> authenticate users via AD.  If you can make sure that AD usernames can
> be used as Unix usernames (keep them short and free of funny characters)
> then this is trivial.
>   
IT already does a decent job of this today since they always make 
matching accounts on the linux NIS server now.
All usernames I've seen are all lowecase alpha characters, Usually 9 
characters or less (long enough to screw up ls output but not too long. ;)

Is Kerberos only needed if I use SFU, and logins are done against AD? Or 
are is it required even with a separate Name Service for logins?

I've been debating with myself whether to convert my NIS to NIS+ to get 
the SecureRPC's and enable SecureNFS... Or to convert to LDAP and either 
Secure RPC/NFS, or Kerberos. or just keep it simple and stick ith NIS, 
and wide open NFS for simplicity.... The NIS+/SecureNFS combo I've done 
before, so setting that up doesn't seem that bad. The LDAP/Kerberos 
combo I've never done, but I know it is the future and more likely to be 
useful when I start to factor AD into the picture. If I can use my own 
LDAP, with 'referals' or proxies to some user and group from AD, then it 
might make sense to bite the bullet and go with LDAP and Kerberos now... 
Especially if Linux nss_ldap can be setup to work through my LDAP server 
to AD.
> That's going to have to change.
>   
It will. At least it will for any machines I manage. If I stick with my 
own Name service, I'll be making that available to anyone ho wants to 
use it on Linux machines they manage (Most are developer's machines, or 
Lab (Dev and QA) machines with no central management. Some get 
reinstalled so often they won't spend much time actually in a domain of 
any type.

If IT will do SFU it'll be a little trickier... I'll have to show 
everyone how to use my Name Services for AutoMount maps, and other UNIX 
tables, but get User and Group info from SFU/AD. Not impossible... just 
not as straight forward as a single NameService.

And that's only if I understand all this correctly!

   Thanks... I'll go read more now. :)
_______________________________________________
opensolaris-discuss mailing list
[email protected]

Reply via email to