NIS problem solved with IY06887 but other problem

NIS problem solved with IY06887 but other problem

Post by Rauscher Guente » Wed, 14 Jun 2000 04:00:00



Dear AIX users,

the problem that NIS passwords could not be changed on AIX 4.3.3 is
solved. I installed the Fix IY06887 on the server and the cllients. With
the assisance of IBM Software Service we found out, that there must be
made changes in files on the server and clients:
/usr/lib/security/methods.cfg:
NIS:
    /usr/lib/security/NIS
DCE:
    program = /usr/lib/security/DCE

/etc/security/user:
default stanza:    registry = NIS
root stanza :         registry = files

I can change the NIS password from the clients now.

But on the other hand I can not change the password and cannot give an
initial passord on the server.
If I would like to look the parameters of a user via smit as root
"Change / Show Characteristics of a User", i get only the output in the
line:   Login Authentication Grammar          [compat] . All other lines
are empy!
The command "lsuser" shows the same.
I can enter a new user, but I cannot remove him.

If I su to any user,  and go into smit, I can see the characteristics of
users.

Is there anybody, who has experiences like this?

Guenter Rauscher

 
 
 

NIS problem solved with IY06887 but other problem

Post by Rauscher Guente » Fri, 16 Jun 2000 04:00:00


I found, that the problem is caused by the additional entries
in /etc/security/users. If  I remove the entries :
default stanza:    registry = NIS
root stanza :         registry = files
... the parameters of a user will be shown in smit to root, but the NIS
password
cannot be changed again on the client.

Guenter Rauscher


> Dear AIX users,

> the problem that NIS passwords could not be changed on AIX 4.3.3 is
> solved. I installed the Fix IY06887 on the server and the cllients. With
> the assisance of IBM Software Service we found out, that there must be
> made changes in files on the server and clients:
> /usr/lib/security/methods.cfg:
> NIS:
>     /usr/lib/security/NIS
> DCE:
>     program = /usr/lib/security/DCE

> /etc/security/user:
> default stanza:    registry = NIS
> root stanza :         registry = files

> I can change the NIS password from the clients now.

> But on the other hand I can not change the password and cannot give an
> initial passord on the server.
> If I would like to look the parameters of a user via smit as root
> "Change / Show Characteristics of a User", i get only the output in the
> line:   Login Authentication Grammar          [compat] . All other lines
> are empy!
> The command "lsuser" shows the same.
> I can enter a new user, but I cannot remove him.

> If I su to any user,  and go into smit, I can see the characteristics of
> users.

> Is there anybody, who has experiences like this?

> Guenter Rauscher


 
 
 

NIS problem solved with IY06887 but other problem

Post by John McQu » Fri, 16 Jun 2000 04:00:00


Rauscher,

I too had problems with NIS after upgrading to Aix 4.3.3 and I posted a
newsgroup request several weeks ago.

I'd already installed the patch you mentioned with no effect. I ended up
having to change the directory in which my copy of the passwd file resides
from /var/yp to /var/yp/d49nis, our NIS domain, and modifying the syssrc
entries and the NIS makefile to reflect this. I also changed the yppasswd to
use the -r rather than the -m option.

I did get yppasswd changes to work on the NIS server but only under certain
circumstances. It doesn't work if you are su'd to root from another user but
if really logged in as root, only allowable on our console, then it worked.
This may be because su looks in the netid map not the group map.

As for the other configuration issues you mention the entry in
/usr/lib/security/methods.cfg hasn't altered on our system for a long time,
it's dated last summer but it looks the same as your sample.

As for the /etc/security/user stanzas, the only user in ours that has
registry set is supman, root & default don't quote it at all.

Hope this is of some help.

Kindest Regards

John McQue
IMS Health


> Dear AIX users,

> the problem that NIS passwords could not be changed on AIX 4.3.3 is
> solved. I installed the Fix IY06887 on the server and the cllients. With
> the assisance of IBM Software Service we found out, that there must be
> made changes in files on the server and clients:
> /usr/lib/security/methods.cfg:
> NIS:
>     /usr/lib/security/NIS
> DCE:
>     program = /usr/lib/security/DCE

> /etc/security/user:
> default stanza:    registry = NIS
> root stanza :         registry = files

> I can change the NIS password from the clients now.

> But on the other hand I can not change the password and cannot give an
> initial passord on the server.
> If I would like to look the parameters of a user via smit as root
> "Change / Show Characteristics of a User", i get only the output in the
> line:   Login Authentication Grammar          [compat] . All other lines
> are empy!
> The command "lsuser" shows the same.
> I can enter a new user, but I cannot remove him.

> If I su to any user,  and go into smit, I can see the characteristics of
> users.

> Is there anybody, who has experiences like this?

> Guenter Rauscher

 
 
 

1. Secure NFS and NIS+ problem solved

Hello,

I've been trying to figure out a problem with secure NFS and NIS+
lately (I'm using Solaris 8) and I think I've finally found a
solution.  I've seen other postings reporting the same kinds of
problems without any real answers so I thought I'd post my results.
I'd been using NIS+ for a while for standard authentication, etc, but
just couldn't seem to get secure NFS working.  I'm not an expert with
all of the details and terminology, but I'll try to explain what I've
found.

To review the problem, I was attempting to share a file system with
the -o sec=dh option and mount it on the clients also with the sec=dh
option.  When mounting the filesystem on a client, the mount command
would execute without any errors, but when trying to cd or ls at the
mount point I would get errors such as "Invalid argument".  In my log
files on the client side I got entries:
  NOTICE: authdes_create: unable to get client's netname, rpc status
16

I had made sure that I had all the involved hosts listed in the
hosts.org_dir table and everything and had credentials created for
them, to no avail.

The problem for me turned out to be that I was using the dh640-0
authentication scheme rather than the standard DES (or dh192-0).  Of
course, that's not a problem in and of itself because I've been using
dh640-0 successfully for a while for all the standard NIS+ stuff.
From what I've found, dh640-0 is not supported for secure NFS at this
time... it would require additional kernel components that are not yet
packaged/released by sun (if anybody knows differently, let me know).
So, the error about not being able to get the client's netname meant
that it was looking for a dh192-0 credential and since I only had
dh640-0 credentials, it couldn't find what it was looking for.

The solution I ended up implementing was to configure both dh640-0 and
dh192-0 (which is often just referred to as DES) authentication
mechanisms on these machines (clients and the server):

/usr/lib/nis/nisauthconf dh640-0 des

I believe that by putting dh640-0 first, it will be used by default by
everything besides secure NFS.

For me, this meant that I had to create new dh192-0 credentials for
the machine serving the secure NFS filesystem and for all users that
needed to access the secure NFS filesystems. Also, if root on a client
needed access, I had to create dh192-0 credentials for that client
machine.

This is basically of the form:

The newly added credential will show up as auth_type of "DES" in the
cred.org_dir table.

Remember to do a "keylogin -r" on any machines you added new
credentials for.

Hope that is helpful,
-John

2. Seeing 1 network from another

3. NIS+ password/account problem, solved

4. XSane Canon 630U config - So Near but yet so Far

5. NIS+ credentials problems : SOLVED

6. Serial port

7. NIS : auth problem with Linux nis server and SUN sparc nis client

8. news groups

9. Awe64 problem solved. Got another problem instead.

10. 2nd CDROM problem solved - MAKEDEV problem on 3.3

11. problem still not solved token ring problem (3c619rev.b)

12. NAT Problem Solved, New Problem

13. NIS+ Compatibility Mode (NIS Client - calendar problem)?