Operating System - Tru64 Unix
cancel
Showing results for 
Search instead for 
Did you mean: 

Local user management with LDAP authentication over SSL problem

SOLVED
Go to solution
Ivan Ferreira
Honored Contributor

Local user management with LDAP authentication over SSL problem

I just configured a test system to do LDAP authentication with SSL.

Enhanced security is enabled.

The authentication works fine. But the problem is that when I try to run useradd, usermod, groupadd, etc, to manage local accounts, even with the -x local=1 option, the command just hangs.

If I change the /etc/ldapcd.conf configuration to not use ssl and to connect to port 389, then the commands works without problem.

If I trace the command, I get:

open("/etc/ldapcd.conf", O_RDONLY, 0666) = 4
ioctl(4, 0x2000745E, 0x00000000) Err#25 Not a typewriter
fstat(4, 0x000000011FFFBB40) = 0
ioctl(4, 0x2000745E, 0x00000000) Err#25 Not a typewriter
read(4, " #\n # * * * * * * * *".., 8192) = 3411
read(4, 0x0000000140136808, 8192) = 0
read(4, 0x0000000140136808, 8192) = 0
ioctl(4, 0x2000745E, 0x00000000) Err#25 Not a typewriter
close(4) = 0
open("/etc/nsswitch.conf", O_RDONLY, 0666) = 4
ioctl(4, 0x2000745E, 0x00000000) Err#25 Not a typewriter
fstat(4, 0x000000011FFFB670) = 0
ioctl(4, 0x2000745E, 0x00000000) Err#25 Not a typewriter
read(4, " # \n # * * * * * * *".., 8192) = 2304
read(4, 0x0000000140144808, 8192) = 0
read(4, 0x0000000140144808, 8192) = 0
ioctl(4, 0x2000745E, 0x00000000) Err#25 Not a typewriter
close(4) = 0
open("/etc/hosts", O_RDONLY, 0666) = 4
open("/etc/ipnodes", O_RDONLY, 0666) = 5
fstat(4, 0x000000011FFFB730) = 0
ioctl(4, 0x2000745E, 0x00000000) Err#25 Not a typewriter
read(4, " #\n # * * * * * * * *".., 8192) = 2626
read(4, 0x0000000140144808, 8192) = 0
gettimeofday(0x000000011FFF97A8, 0x00000000) = 0
getpid() = 1251021 [ 1251015 ]
open("/etc/resolv.conf", O_RDONLY, 0666) = 6
fstat(6, 0x000000011FFF9690) = 0
ioctl(6, 0x2000745E, 0x00000000) Err#25 Not a typewriter
read(6, " d o m a i n s i s . p".., 8192) = 75
read(6, 0x0000000140147008, 8192) = 0
close(6) = 0
socket(AF_INET, SOCK_DGRAM, PF_UNSPEC) = 6
connect(6, 0x000003FFC00B9374, 16) = 0
send(6, 0x000000011FFFABA8, 44, ) = 44
gettimeofday(0x000000011FFFA698, 0x00000000) = 0
select(7, 0x000000011FFFA750, 0x00000000, 0x00000000, 0x000000011FFFA690) = 1
recvfrom(6, 0x0000000140149800, 65536, 0, 0x000000011FFFA680, 0x000000011FFFA678) = 60
close(6) = 0
close(4) = 0
close(5) = 0
socket(AF_INET, SOCK_STREAM, PF_UNSPEC


Any ideas?
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
5 REPLIES
Ivan Ferreira
Honored Contributor

Re: Local user management with LDAP authentication over SSL problem

More information:

If I run

groupadd -x local=1 testgroup

And I do a tcpdump -X at the LDAP server, I can see the connection to the port 636 (LDAP+SSL) coming from the Tru64 Box. The interesting thing is that I can see the username and password used for the connection, so, that manas that groupadd is ignoring the "usessl" option in ldapcd.conf, because the communication is not encrypted. But why it tries to contact the LDAP server if the -x local=1 option was given? Two problems here.


Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Ann Majeske
Honored Contributor

Re: Local user management with LDAP authentication over SSL problem

What version/patch kit of Tru64 are you running?

What is the contents of your matrix.conf,
svc.conf, and nsswitch.conf files?
Ivan Ferreira
Honored Contributor

Re: Local user management with LDAP authentication over SSL problem

Hi Ann, I was expecting your answer. I saw you found a solution for previous LDAP authentication problems.


The OS is Tru64 5.1B PK5.


matrix.conf:

siad_setpwent=(BSD,libc.so) (LDAP,/usr/shlib/libsialdap.so)
siad_endpwent=(BSD,libc.so) (LDAP,/usr/shlib/libsialdap.so)
siad_getpwent=(BSD,libc.so) (LDAP,/usr/shlib/libsialdap.so)
siad_getpwnam=(BSD,libc.so) (LDAP,/usr/shlib/libsialdap.so)
siad_getpwuid=(BSD,libc.so) (LDAP,/usr/shlib/libsialdap.so)
siad_chg_finger=(OSFC2,/usr/shlib/libsecurity.so)
siad_chg_password=(OSFC2,/usr/shlib/libsecurity.so)
siad_chg_shell=(OSFC2,/usr/shlib/libsecurity.so)
siad_chk_user=(OSFC2,/usr/shlib/libsecurity.so)
siad_setgrent=(BSD,libc.so) (LDAP,/usr/shlib/libsialdap.so)
siad_endgrent=(BSD,libc.so) (LDAP,/usr/shlib/libsialdap.so)
siad_getgrent=(BSD,libc.so) (LDAP,/usr/shlib/libsialdap.so)
siad_getgrnam=(BSD,libc.so) (LDAP,/usr/shlib/libsialdap.so)
siad_getgrgid=(BSD,libc.so) (LDAP,/usr/shlib/libsialdap.so)
siad_ses_init=(OSFC2,/usr/shlib/libsecurity.so)
siad_chk_invoker=(OSFC2,/usr/shlib/libsecurity.so)
siad_ses_authent=(OSFC2,/usr/shlib/libsecurity.so)
siad_ses_suauthent=(OSFC2,/usr/shlib/libsecurity.so)
siad_ses_reauthent=(OSFC2,/usr/shlib/libsecurity.so)
siad_ses_estab=(OSFC2,/usr/shlib/libsecurity.so)
siad_ses_launch=(OSFC2,/usr/shlib/libsecurity.so)
siad_ses_release=(OSFC2,/usr/shlib/libsecurity.so)
siad_init=(OSFC2,/usr/shlib/libsecurity.so) (LDAP,/usr/shlib/libsialdap.so)

svc.conf:

aliases=local
auth=local
group=local,yp
hosts=local,bind
netgroup=yp
networks=local
passwd=local,yp
protocols=local
rpc=local
services=local

nsswitch.conf:

aliases: files
auth_default: files
auth_devassign: files
auth_files: files
auth_prpasswd: files
auth_ttys: files
group: compat
group_compat: nis
hosts: files dns
netgroup: nis
networks: files
passwd: compat
passwd_compat: nis
protocols: files
rpc: files
services: files


Just consider that everything works if SSL is not enabled, that is, get user information (id, finger, etc), and authentication.

Thanks for your time.
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Ann Majeske
Honored Contributor
Solution

Re: Local user management with LDAP authentication over SSL problem

Hi Ivan,

I'm not absolutely sure that the configuration that you're trying to set up is supported, I know that I certainly haven't tried it! I do have a couple of suggestions and a bunch of information that I put together for someone with a somewhat similar configuration a while back. It might not all be relevant, but hopefully it will be of some help. If you can't get this working and you have a support contract you could consider opening a support call to get a definitive answer as to if this configuration is supported and how to set it up.

I don't see any obvious errors in your configuration files. From your description, the issue is likely in the useradd, etc commands themselves. My area of expertise is more in the SIA area. One side effect of LDAP being handled as an sia mechanism rather than a name service switch entry (more in the additional information below) is that the useradd, etc. commands will see LDAP as local rather than distributed unless there is specific workaround code in the commands to prevent this. I'm not going to express an opinion as to whether this is a bug or expected behavior for the commands, I'll leave that up to the commands experts :)

One thing to try would be to remove all of the NIS references from the nsswitch.conf and svc.conf files (including the passwd_compat and group_compat entries) files using the nssetup tool. If the useradd, etc. commands are getting "confused" by your configuration this removes one possible area of confusion.

Another thing to try would be to stop and disable the prpasswdd daemon (instructions below). There's a similar rationale for this suggestion, removing the prpasswdd daemon from the equation simplifies things.

You could try using the Audit subsystem to gather information on what the commands are trying to do at the time that they hang.

Additional Information:

As long as you are running a version that has nsswitch.conf (later patch kits of V5.1B) then you should primarily be changing nsswitch.conf, not svc.conf. If you're running a version that has nsswitch.conf then the system will use nsswitch.conf for everything except for pre-nsswitch statically built applications and Sendmail.
- svc.conf doesn't have any support for ldap.
- nsswitch.conf support for ldap is limited to using the ldap source for the netgroup database, e.g. the entry:
netgroup: ldap nis
is supported.
Somehow this didn't get put on the man page.
- the majority of ldap support in Tru64 UNIX is supplied by the LDAP SIA mechanism instead of nsswitch.conf or svc.conf. The LDAP SIA mechanism is separate from the Enhanced Security SIA mechanism and the LDAP SIA mechanism doesn't include the Enhanced Security features. But, you can have multiple SIA mechanisms loaded on the system, so you can do a limited combination of the two.

The reason for some LDAP support being through the LDAP SIA mechanism and some through the nsswitch is that we only added the nsswitch recently so it only has the support that couldn't be supported through the existing SIA mechanism, instead of converting all of the SIA functionality to work through the nsswitch instead.

I don't know much more about nsswitch than is available in the man pages. But in this case I think you should be able to use "files" as the source for the passwd and group databases. This should cause the nsswitch to just fall through to the SIA mechanisms which will do the right thing once the LDAP SIA mechanism is setup. I think the "compat" source is to allow a fallback to the old way of doing things which was to go to NIS if there were any + or - entries in the passwd or group databases, otherwise just stay local (more or less equivalent to a source of "files nis"). The passwd_compat and group_compat database entries could then be used to specify a source other than NIS for the + and - entries, but the allowed list doesn't include LDAP, so I don't think compat does you any good.

One other thing I would suggest is stopping and disabling the prpasswdd daemon on your systems, at least while you're trying to set this up. The prpasswdd daemon isn't required for the system to work properly, it was added as a performance enhancement for systems and clusters that do many (very many!) logins at the same time.
To stop the prpasswdd on the running system:
# /sbin/init.d/prpasswd stop
To prevent the prpasswdd daemon from starting on system startup:
# rcmgr -c set PRPASSWDD_ARGS -disable

The sialog (see man sialog) might be useful in debugging the SIA setup, but it should only be used for debugging and turned off when debugging is completed. The sialog is not designed for long term use for auditing logins and logouts, the Audit subsystem should be used instead. It wouldn't hurt to have the Audit subsystem enabled, too. The Audit subsystem is useful in many debugging situations as well as for long term auditing of system functions. See Chapter 3 of the Security Administration guide and http://h30097.www3.hp.com/docs/best_practices/BP_AUDIT/TITLE.HTM

Ivan Ferreira
Honored Contributor

Re: Local user management with LDAP authentication over SSL problem

That was a really good answer. I will do some test again and post the results, but as you said, I think that the problem is with the comands itself.

Thanks for your help.
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?