Gordon, I didn't read your first posting. So this email may not make a sense. Sorry.
We just converted UNIX traditional authentication method to use Active Directory. As you may know, AD is Microsoft's LDAP solution. Our current production UNIX platforms are: OS: HP-UX 11.11 64-bit UniData 5.2.8 We decided to purchase Vintella Authentication Service (VAS) to integrate AD and UNIX user password synchronization. In order to use VAS, PAM (Pluggable Authentication Modules) had to be installed in all HP-UX boxes. So applications that are aware of PAM (using libpam.a), like sshd, worked fine without changing. However, UniData we are using is not built with libpam.a (ie. UniRpcD, udapi_server, and udapi_slave. How did I find it? I used ldd command against a binary file.). That broke our UniObject for Java sessions; connect() method stopped working. Yicks! Enough about Ferguson stuff... Getting bored, eh? Anyway, if I were you, I would try this: Option 1: I think it's using LDAP, but maybe not... Let's find out. Create a tiny C or Perl program to find what password field returns when calling getpwnam() function. If password field contains *, then most likely you are using a shadow password file. Use getspnam() for that and execute the little program being root. If a crypted password string returned, make sure that UniData (maybe Universe?) daemon processes owned by root. Shadow password can be read only by root or applications with root juice. :) Then I would try your UniObject application. Option 2: Oh, darn...Option 1 didn't work. And we cannot ditch LDAP authentication. Create a local special UNIX user in your server side (meaning, the user's password stored in traditional UNIX password file with crypted password in password field) 1. In your client application, authenticate connecting users using JNDI if your application is written in JAVA or ADSI if your application is written in Visual Basic (System.Directoryservices for .NET) before calling UniObject routines. 2. Use that special UNIX user to open a UniObject session. Bad (?) thing about the above implementation is that the special user will be an owner of a file, not actual user, when writing a record. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Bennett Sent: Wednesday, March 16, 2005 6:25 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UniObjects and LDAP user authentication. Gordon, > Our system admin department just changed our Sun servers from using NIS > (Network Information Name Service) to LDAP Directory Service. It was said > that this user authentication is more secure than NIS. Unfortunately, our > UniObjects quit working. When I try to open a session within a VBA > program or with the UniDebugger it fails due to "Invalid User Name or > Password". doesn't the UniDebugger login using telnet? (I haven't used it for a while). Maybe the username/password you are using is not in LDAP? I would think that LDAP vs NIS should be transparent to the application (unless its SASL, maybe you need to associate a service tag with an authentication method in your SASL config?). Craig ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
