From: David Komanek (xdavid@lib-eth.natur.cuni.cz)
Date: Tue Feb 11 2003 - 02:54:22 EST
Dear all,
I got a few replies to my questions concerning the posibility access
OSF-C2 remotely to gain direct access from client machines (see original
message bellow). Many thanks go to (in order of appearance in my
mbox)
Michael James Bradford
Mehall, Michael
Ann Majeske and Spider Broadman
I now believe the general consensus is:
* it is not possible to connect to OSF-C2 protected databse via a specific
network protocol
* prpasswdd is limited to the conections from localhost and its protocol
is proprietary
* simple solution is to deliver data for requested changes to the serer
machine (i.e. NFS) and then run there scripts based on Expect and edauth
to complete the task
As an add-on Ifound that it is possible to manage some facilities of
user's accounts through NIS cooperating with protected password records.
In the case we already use various custom scripts and krb4 as an
alternative authenticator (which we synchronize with OSF-C2) this is not
suitable solution or me.
Well, because I need real-time feedback and security to the user's
request, I decided to write my own client/server application. Server
(written in poor C-language) will wait for request to supply some data and
to perform administrative tasks on user's acounts. Client will be a
graphical front-end for this written in Java (JFC/Swing) to have single
code for both Windows and Linux platforms. Communication between client
and server is secured by SSL encrypted socket TCP communication. My first
attempts to this seem promissing.
Thank you very much for your opinions.
Sincerely,
David Komanek
=============== Replies ======================================
Hi David,
This can be done by running the edauth command via super and ssh.
For example, you could write a script that took an encrypted password and
used edauth to replace the current encrypt password (u_pwd). The script
would then update the password change time (u_succhg). This script would
be
placed on the individual client hosts and should be owned by root and only
executable by root.
On the server side, you would have a script/program which allowed the
input
of a password and encrypted it. It would then run the client-based script
via ssh. If the user running it is not root, then you would need "super"
to
call ssh.
Hope this helps
Michael Bradford
TDC Services IT
--------------------------------------------------------------
David,
I have developed my own method for changing a c2 (or non-c2 for
that matter) password on multiple UNIX servers. It involves two ksh
scripts and an Expect script. The expect program requires that tcl and
Expect packages are loaded on your control server and the scripts also
expect a common NFS mounted filesystem across all servers. If you are
interested in the scripts let me know and I'll send you a copy of
everything. Also, the script works for 4.0x and 5.0. It has not been
tested in 5.1a.
Mike Mehall
SAP Basis Team
Northrop Grumman Corp.
--------------------------------------------------------------
Hi David,
In order to use the Enhanced Security (ES) interfaces, you'll need to be
on a Tru64 UNIX machine. That can be managed by something like rsh "under
the hood" of whatever application you develop, of course. You're really
best off using 'expect'-like processing and the /usr/bin/passwd command
rather than trying to roll your own interface here - especially since this
protects you against possible changes in the interfaces. [A custom
daemon, which you already said you'd prefer not to use, could make the
sia_chg_passwd() call directly, of course.] Going 'below' the
sia_chg_passwd(3) or passwd(1) interfaces is where you'd have the
potential to get into trouble down the road.
[/usr/sbin/prpasswdd uses a proprietary protocol from the putespwnam(3)
interface, and it demands that the application 'talking' to it must be on
the same machine as it is - with a special hack for TruCluster access.
Trying to talk to it directly is not likely to get you what you want.]
Hope this helps, even though it's not quite what you wanted to hear.
[Ann Majeske and Spider Broadman]
--------------------------------------------------------------
David,
I went down the same road last year and didn't have the resources,
or time, to write a Client/Server app. Also, I tried to write a program
that called the C2 libraries myself and after much discussion with many of
the Tru64 managers group members I decided that an Expect program that
directly interacted with the passwd command was my best bet. Well, good
luck and I am anxious to see a summary on this one!
Mike Mehall
SAP Basis Team
Northrop Grumman Corp.
=============== Original message =============================
> Dear admins,
>
> I am trying to simplify the user's account management (about 3500 users in
> heterogenous network). One of the problems I have is to explore the
> possibility of changing tru64unix C2-security password without the need of
> interactive logging to the shell. My idea is not to use a web-based
> application on the server side. I would like to implment this as a
> standalone application (which will serve various functions for various
> accounts on various machines :-) Is it possible ? I think it should be
> done using prpasswd daemon but not sure how to use it, because I found no
> prorammer's API reference for this.
>
> I am able to manipulate with prpasswd entries locally, so the only thing I
> need is the way to communicate with C2 database remotely without the need
> of writing my own special daemon listening on a privileged port.
>
> Thanks in advance,
>
> David Komanek
> Charles University
> Faculty of Science
> CZ, Prague
> komanek@natur.cuni.cz
>
>
--
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:07 EDT