HP-UX NIS client + Linux (Red Hat AS 2.1) NIS server auth issues

[Chris Rutledge_2]

Are there any known password encryption issues between HP-UX (client) and Linux NIS (server)?

I've got a HP-UX 11.11 client with a Red Hat AS 2.1 NIS server and I receive "Wrong password given for user" and subsequently a "Authentication failed for user" when sshing or any other login method requiring a password to be given. Su-ing from root I'm able to get in as that user and all other NIS capability is present. All other linux clients are having no issues.

[Dave Olker]

Hi Chris,

I don't have access to a RH AS 2.1 system, but I configured my RH 8 system as an NIS server and configured my 11i system as a client to the RH8 server. I was able to login to the 11i box without a problem (once I changed my passwd entry in the NIS map to include /bin/ksh as my shell, as I don't have /bin/bash on my 11i system).

I don't know of a "class" problem with 11i systems working with RH AS 2.1 systems, and it is working fine with my RH8 system.

Is everything else working on the 11i system from an NIS perspective? In other words, can you get the list of maps with ypwhich -m? Can you "ypcat -k" any of the maps? Does the problem only occur for certain users? How about newly created users?

Regards,

Dave

[Steven E. Protter]

I know of know issues, but would not be surprised if they exist.

I've had very inconsistent performance on the various red hat platforms with samba/cifs and would not be surprised.

If you turn on enhanced logging on your hp system you might get better diagnostic information.

If there is a specific problem, you might catch it by turning on a packet sniffer like ethereal or tcpdump.

SEP

[Victor Fridyev]

Hi,

If a password, which was set on LINUX is longer than 8 characters, this may cause a problem in HPUX.

HTH

[Chris Rutledge_2]

All yp* functions on the maps are present and seem to be working fine. I've only tried a few users, including a newly created user with the same results.

I've tried turning on debugging for the HP client via YPBIND_OPTIONS="-v -ypset" in the /etc/rc.config.d/namesvrs...after shutting it down and restarting the client it is unable to bind to the server. Is there another method I should be using to turn on debug for the HP client?

I've also turned on debugging on the server (without having debugging on the client) and the output looks normal...no errors. It pulls the entries from the maps just fine. I could have missed something though...I'm posting the servers debug information.

I've also set the passwords for a few users <8 with no luck.


Background info: The client and server on are separate networks 192.192.192. (client) and 10.254.0.0 (server). There is a firewall separating them, however, all access is granted.

Thx
- Chris

[Dave Olker]

Hi Chris,

NIS is one of the only RPC subsystems on HP-UX where there really isn't a very good debug logging subsystem. We provide good logging for rpc.lockd, rpc.statd, automount, rpc.mountd, etc. but NIS doesn't have a good debug facility.

My suggestion would be to collect a network trace of the failing login attempt and a working login attempt from another system and analyze the network traces to see why the HP login attempt is failing.

Regards,

Dave

[Chris Rutledge_2]

Here is what I found from a tcpdump on the HP client....."Unknown authentication flavor - cannot dissect". A quick search on google didn't turn up much.

What password encryption does HP support (11.11)...3des/md5?


- Chris

[Chris Rutledge_2]

OK...The client makes the match call and the server replies however, the client is unable to dissect the packet????

Does anyone thing if I called HP for support (with linux in the mix) they would help me on this?

I'm posting the tcpdump files for your viewing pleasure....

client packet numbers: 543 and 544
server packet numbers: 881 and 882

- Chris

[Chris Rutledge_2]

Server file....

[Dave Olker]

Hi Chris,

I'm sorry that I don't have time to look at the data myself right now, but I can say that I've worked on numerous HP-UX/Linux interoperability issues for HP customers, and those issues came in via the Response Center.

I don't think you'd be turned away by HP support if you opened a call with them.

Regards,

Dave

[Chris Rutledge_2]

Thanks for your help...I'll give HP support a call on this Monday morning.



Thanks again,
Chris

[Chris Rutledge_2]

Calling HP support.