Re: Sparc Solaris NIS client Linux NIS server
- From: Chris Cox <ccox_nopenotthis@xxxxxxxxxxx>
- Date: Mon, 12 Dec 2005 19:24:29 -0600
dogdog@xxxxxxxxxxx wrote:
> On Sat, 10 Dec 2005 17:49:28 +0000, Chris Cox wrote:
>
>>dogdog@xxxxxxxxxxx wrote:
>>>I'm cross posting this from comp.unix.solaris in hopes
>>>that the linux admins can help or have had similiar
>>>experience.
>>>
>>>Sunfire V240 Solaris 8 02/04. I've configured it as a
>>>nis client. I logon as root (local account). Verify that it sees
>>>the nis master (ypwhich), verified that it can cat the hosts file
>>>(ypcat hosts), verified that it can see the passwd file (ypcat
>>>passwd). These all work. I have also the ability to (when logged
>>>in as root) su - <username> and become a user (whereas the user
>>>is a NIS user with account information and home directory on the
>>>Linux NIS server). What I cant do is logon via the CDE logon
>>>screen. I get the "incorrect logon" error.
>>>
>>>I've ran ethereal to check the connection and the closest anomaly
>>>I found was that when logging on the Solaris box via CDE it is not sending
>>>the logon credentials to the Linux NIS server, therefore not getting a response
>>>back that its a valid logon. Now, this isnt the end. I also ran
>>>ethereal against a telnet session to the solaris box, and I did see
>>>it send the username over the wire to the NIS server, but again
>>>got an incorrect logon error.
>>>
>>>Has anyone seen this?? I'm thinking a patch or something since the
>>>sparc is freshly built with no patches.
>>NIS doesn't "send the username/password" over the wire, ... well
>>not the way you make it sound. It merely looks them up out of
>>the NIS tables available to the client (which do go across the
>>wire or out of cache... which I don't recommend).
>>
>>We replaced our Solaris NIS server with a Linux one years ago.
>>Everything works fine. Including logging on using CDE on those
>>clients.
>>
>>Check your nsswitch.conf on your Solaris client.
>
> I'll check over the nsswitch.conf and verify that its right. But
> I'd differ on the not sending the information over the wire.
> From what I've seen on an ethereal dump its certainly sending
> the username over and requesting verification, if this is a lookup
> or not is basically unimportant since the information is on the
> wire and is trying to verify
> based on a NIS map and it is responding
> back, I can verify if its the shadowed passwd or not but I believe
> it may be. Its always been my understanding, other than the ability
> to just simply ypcat passwd, that this is one of the inherent
> insecurities with NIS. I can say that I did see the username
> going in the clear.
Certainly. Shadow maps are NOT NIS... they are an extension
and not well supported. About the only thing you can count
on portably is DES encrypted password strings in your
passwd maps. If you are using NIS with shadow maps, you
are using something that is NIS-like... but not NIS.
In portable NIS the authentication is done locally using
the encrypted password strings from the passwd map just
like using the local /etc/passwd file.
If the number of accounts are small (not in the 10,000's) then
managing users with NIS is much simpler than with .. let's say...
LDAP. If you have an existing Windows infrastructure, it's
fairly trivial to auto create NIS users based on Windows
account data and tie the password back to the Windows
password server (which may bother Unix purists... but does
work.. and if you've got the ugly animal there anyway...
might as well use it).
I've used the technique at a platics production facility
with good success. You just add users to the Windows domain
(pretty much assumes a single Windows domain) and then
they automatically get NIS accounts when they log into
Windows the first time... just that the NIS DES
encrypted password is nuked (untypable) and the boxes
do their auth NTLM style to the Windows password
server. Or.. even better, don't use NTLM at all and
just load an SSH key which comes off a shared drive
in NFS/Samba space (home dirs) at Windows login time and tell them
to PuTTY into the client hosts... then they don't
have to use a password once they've logged into
the Windows client.
.
- Follow-Ups:
- Re: Sparc Solaris NIS client Linux NIS server
- From: Nico Kadel-Garcia
- Re: Sparc Solaris NIS client Linux NIS server
- References:
- Sparc Solaris NIS client Linux NIS server
- From: dogdog
- Re: Sparc Solaris NIS client Linux NIS server
- From: Chris Cox
- Re: Sparc Solaris NIS client Linux NIS server
- From: dogdog
- Sparc Solaris NIS client Linux NIS server
- Prev by Date: Re: Sparc Solaris NIS client Linux NIS server - solution
- Next by Date: Re: Sparc Solaris NIS client Linux NIS server - solution
- Previous by thread: Re: Sparc Solaris NIS client Linux NIS server
- Next by thread: Re: Sparc Solaris NIS client Linux NIS server
- Index(es):
Relevant Pages
|