- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- Local user management with LDAP authentication ove...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-22-2007 07:24 AM
тАО06-22-2007 07:24 AM
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-22-2007 07:46 AM
тАО06-22-2007 07:46 AM
Re: Local user management with LDAP authentication over SSL problem
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-22-2007 09:09 AM
тАО06-22-2007 09:09 AM
Re: Local user management with LDAP authentication over SSL problem
What is the contents of your matrix.conf,
svc.conf, and nsswitch.conf files?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-23-2007 06:15 PM
тАО06-23-2007 06:15 PM
Re: Local user management with LDAP authentication over SSL problem
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2007 07:42 AM
тАО06-25-2007 07:42 AM
SolutionI'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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-26-2007 02:35 AM
тАО06-26-2007 02:35 AM
Re: Local user management with LDAP authentication over SSL problem
Thanks for your help.