[Freeipa-devel] Re: nis plug-in setup question

Nalin Dahyabhai nalin at redhat.com
Wed May 6 20:52:34 UTC 2009


On Wed, May 06, 2009 at 12:46:25PM -0700, yi zhang wrote:
> Nalin:
> I need your help to determine whether I have any missed step(s) in my  
> configuration.
>
> I am trying to config IPA (v2) server as NIS server. And here is the  
> config I have in ds
> ---
> dn: cn=NIS Server, cn=plugins, cn=config
> objectClass: top
> objectClass: nsSlapdPlugin
> objectClass: extensibleObject
> cn: NIS Server
> nsslapd-pluginPath: /usr/lib/dirsrv/plugins/nisserver-plugin.so
> nsslapd-pluginInitfunc: nis_plugin_init
> nsslapd-pluginType: object
> nsslapd-pluginEnabled: on
> nsslapd-pluginDescription: NIS Server Plugin
> nsslapd-pluginVendor: redhat.com
> nsslapd-pluginVersion: 0
> nsslapd-pluginID: nis-plugin
> nis-tcp-wrappers-name: ypserv
> nsslapd-pluginarg0: 514

Looks fine.

> dn: nis-domain=idm.lab.bos.redhat.com+nis-map=users,cn=NIS  
> Server,cn=plugins,cn=config
> objectclass: extensibleObject
> nis-domain: idm.lab.bos.redhat.com
> nis-map: users
> nis-base: ou=People, dc=example, dc=com
> nis-base: ou=nisGroup, ou=nisaccounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
> nis-filter: (objectClass=posixAccount)
> nis-key-format: %{uid}
> nis-value-format:  
> %{uid}:%{userPassword-:*}:%{uidNumber}:%{gidNumber}:%{gecos:-%{cn:-Some  
> Unnamed User}}:%{homeDirectory}:%{loginShell:-/bin/bash}
> nis-disallowed-chars: :

This is the problem.  NIS clients expect the maps which serve up
information about users to be named "passwd.byname" (keyed by user name)
and "passwd.byuid" (keyed by UID).  You need both.  These names are
hard-coded into the clients, so the maps you define must have the names
that the clients expect them to have.

The plugin has defaults built-in for maps named "passwd.byname",
"passwd.byuid" and many of the commonly-used maps, so you can omit the
'nis-filter', 'nis-key-format', 'nis-value-format', and
'nis-disallowed-chars' settings for those maps to save yourself some
work.  (Run "nisserver-plugin-defs -m passwd.byname" if you want to
examine the defaults for a map with that name.)

In the 'nis-value-format' you're using above, "%{userPassword-:*}"
should probably be "%{userPassword:-*}" if I understand what you're
trying to do.

> I have such data there:
>
> [root at mv32a-vm nis-plugin]# /usr/lib/mozldap/ldapsearch -D "cn=directory  
> manager" -w redhat123 -s sub -b  
> "ou=nisaccounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" "uid=nisuser*"
> version: 1
> dn: uid=nisuser12, ou=nisGroup,  
> ou=nisaccounts,dc=idm,dc=lab,dc=bos,dc=redhat,
> dc=com
> objectClass: top
> objectClass: posixAccount
> cn: nisuser
> uid: nisuser12
> uidNumber: 30001
> gidNumber: 3001
> homeDirectory: /home/nisuser01
> loginShell: /bin/bash
> userPassword: {SSHA}n0nwUjq6mn9e2jU8ZOotg6vjN3GA/g20R3jPyw==

There's a very good chance that a POSIX client won't be able to verify
passwords using a {SSHA} password, not portably anyway.  You can really
only depend on {CRYPT} hashed passwords, and then you want to strip off
the {CRYPT} before handing the value to the client.  The compiled-in
default uses a regex substitution to (try to) get the right thing to
happen here.

The point I'm dancing around is that I recommend using the defaults for
maps like this one.  My hope is that most people won't have to worry
about working out the right key- and value format specifiers to use in
their configurations.

> After I config one nis client connect to this server  
> (mv32a-vm.idm.lab.bos.redhat.com),
>
> <QA>[root at mv64a-vm ~]# authconfig-tui
> Stopping portmap:                                          [  OK  ]
> Starting portmap:                                          [  OK  ]
> Shutting down NIS services:                                [  OK  ]
> Turning on allow_ypbind SELinux boolean
> Binding to the NIS domain:                                 [  OK  ]
> Listening for an NIS domain server..

Looks good.

> <QA>[root at mv64a-vm ~]#
> <QA>[root at mv64a-vm ~]#
> <QA>[root at mv64a-vm ~]#
> <QA>[root at mv64a-vm ~]#
> <QA>[root at mv64a-vm ~]# getent passwd | grep nisuser
> <QA>[root at mv64a-vm ~]# rpcinfo -p mv32a-vm.idm.lab.bos.redhat.com
>   program vers proto   port
>    100000    2   tcp    111  portmapper
>    100000    2   udp    111  portmapper
>    100024    1   udp    918  status
>    100024    1   tcp    921  status
>    100021    1   udp  36144  nlockmgr
>    100021    3   udp  36144  nlockmgr
>    100021    4   udp  36144  nlockmgr
>    100021    1   tcp  39591  nlockmgr
>    100021    3   tcp  39591  nlockmgr
>    100021    4   tcp  39591  nlockmgr
>    100004    2   udp    541  ypserv
>    100004    2   tcp    541  ypserv

That looks right, except that your configuration appears to be
specifying port 514, and the server appears to be listening on port 541.

> <QA>[root at mv64a-vm ~]# ssh nisuser12 at mv64a-vm.idm.lab.bos.redhat.com
> The authenticity of host 'mv64a-vm.idm.lab.bos.redhat.com  
> (10.16.98.120)' can't be established.
> RSA key fingerprint is db:dc:f5:7b:85:4b:2f:d7:be:27:40:5d:b8:0a:c0:a6.
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added  
> 'mv64a-vm.idm.lab.bos.redhat.com,10.16.98.120' (RSA) to the list of  
> known hosts.
> nisuser12 at mv64a-vm.idm.lab.bos.redhat.com's password:
> Permission denied, please try again.
> nisuser12 at mv64a-vm.idm.lab.bos.redhat.com's password:
> Permission denied, please try again.
> nisuser12 at mv64a-vm.idm.lab.bos.redhat.com's password:
> Permission denied (publickey,gssapi-with-mic,password).
>
> <QA>[root at mv64a-vm ~]# vi /var/log/secure
> May  6 03:23:57 mv64a-vm sshd[2979]: pam_succeed_if(sshd:auth): error  
> retrieving information about user nisuser12

This is consistent with the client's NIS support not finding a
passwd.byname map, or not finding an entry that matches the user in it.

[snip]
> yp.conf on client (mv64a-vm) has only one line
> domain idm.lab.bos.redhat.com server mv32a-vm.idm.lab.bos.redhat.com

That looks right.

> /etc/nsswitch.conf has
> hosts:      files nis dns
>
> firewall is not an issue, i stopped iptables on both client and server
>
> What I did wrong?

If you're looking for user information, then the 'passwd:' line is the
interesting one, though authconfig should have set that up correctly.

HTH,

Nalin




More information about the Freeipa-devel mailing list