<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Forcing su rather than allowing telnet login for specific accounts in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202541#M748680</link>
    <description>I forgot about CDE logins. Users with Reflection X or Exceed can directly login to the systems with CDE. /etc/profile|csh.login won't help you in that case. You will need to place a X startup script with the same logic. For ex., Create a script called&lt;BR /&gt;&lt;BR /&gt;0000.directlogin under /etc/dt/config/Xsession.d with 555 permissions.&lt;BR /&gt;&lt;BR /&gt;Add the following shell into it&lt;BR /&gt;&lt;BR /&gt;grep -q "^${USER}:" /etc/nodirectlogin&lt;BR /&gt;if [ $? = 0 ]&lt;BR /&gt;then&lt;BR /&gt;/usr/dt/bin/dterror.ds "CDE login denied for $USER" "Login Denied" "Exit"&lt;BR /&gt;exit 1&lt;BR /&gt;fi&lt;BR /&gt;&lt;BR /&gt;This should disable all the users under /etc/nodirectlogin to logon via CDE.&lt;BR /&gt;&lt;BR /&gt;-Sri</description>
    <pubDate>Wed, 25 Feb 2004 19:08:38 GMT</pubDate>
    <dc:creator>Sridhar Bhaskarla</dc:creator>
    <dc:date>2004-02-25T19:08:38Z</dc:date>
    <item>
      <title>Forcing su rather than allowing telnet login for specific accounts</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202535#M748674</link>
      <description>I'm trying to figure out how to secure application accounts on a production server. Our policy is that users should login as themselves and then su to the application account - now I need a way to enforce this sequence rather than just suggest it.&lt;BR /&gt;&lt;BR /&gt;Here are the parameters:&lt;BR /&gt;1. Users come from multiple networks (10.x 172.x 192.x - its a long story).&lt;BR /&gt;2. The application accounts use ftp to transfer data among systems, so I can't simply lock the account to force su rather than login.&lt;BR /&gt;3. There are 20 maintainers that need to use these accounts.&lt;BR /&gt;4. Their work is not predictable enough to set up an adequate sudoers file without a lot of work and angst.&lt;BR /&gt;&lt;BR /&gt;I was hoping I could write some shell code that would detect that the UID and EUID were the same for a direct login and different for a su, but it appears that id only returns ids within the current context - the uid and euid are the same after an su.&lt;BR /&gt;&lt;BR /&gt;It also seems to me that I might be able to do this by looking for the parent process for a new shell and making sure that it is an su.&lt;BR /&gt;&lt;BR /&gt;But what I'm really hoping is that someone out there already has a robust, tested, solution for this problem.</description>
      <pubDate>Wed, 25 Feb 2004 18:24:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202535#M748674</guid>
      <dc:creator>Jerry Anderson_5</dc:creator>
      <dc:date>2004-02-25T18:24:23Z</dc:date>
    </item>
    <item>
      <title>Re: Forcing su rather than allowing telnet login for specific accounts</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202536#M748675</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;Check out hp-ux commands "whoami" and "who am i". One returns the username before su while the other returns the username su'ed into. That should provide you with the corresponding uid and euid that you need.&lt;BR /&gt;&lt;BR /&gt;Hope this helps. Regards.&lt;BR /&gt;&lt;BR /&gt;Steven Sim Kok Leong</description>
      <pubDate>Wed, 25 Feb 2004 18:32:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202536#M748675</guid>
      <dc:creator>Steven Sim Kok Leong</dc:creator>
      <dc:date>2004-02-25T18:32:09Z</dc:date>
    </item>
    <item>
      <title>Re: Forcing su rather than allowing telnet login for specific accounts</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202537#M748676</link>
      <description>Well for the root account set up the /dev/securetty file with the word console in it.&lt;BR /&gt;For other specific accounts, simply lock them. You can use either 'passwd -l' or replace the encryption with a '*' in the /etc/passwd file. See the man page for passwd.&lt;BR /&gt;$ man 1 passwd</description>
      <pubDate>Wed, 25 Feb 2004 18:35:15 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202537#M748676</guid>
      <dc:creator>Michael Tully</dc:creator>
      <dc:date>2004-02-25T18:35:15Z</dc:date>
    </item>
    <item>
      <title>Re: Forcing su rather than allowing telnet login for specific accounts</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202538#M748677</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;You can leverage the "who am i" output to find out the base user and then restrict them for direct login. For ex., the following sample code will look for the user in /etc/nodirectlogin and exits if so for direct logins.&lt;BR /&gt;&lt;BR /&gt;ME=$(who am i|awk '{print $1}')&lt;BR /&gt;grep -q "^${ME}:" /etc/nodirectlogin&lt;BR /&gt;if [ $? = 0 ]&lt;BR /&gt;then&lt;BR /&gt;echo "$ME cannot login directly. Login with your own id and then SU to $ME"&lt;BR /&gt;exit&lt;BR /&gt;fi&lt;BR /&gt;&lt;BR /&gt;You will need to add the generic logins in your /etc/nodirectlogin file as follows&lt;BR /&gt;&lt;BR /&gt;oracle:Oracle account&lt;BR /&gt;sybase:Sybase Generic account&lt;BR /&gt;&lt;BR /&gt;etc., etc.,&lt;BR /&gt;&lt;BR /&gt;However, these accounts will allow the users to do a 'su' to them. &lt;BR /&gt;&lt;BR /&gt;You will also need to customize your csh.login for accounts with csh shell.&lt;BR /&gt;&lt;BR /&gt;This is not a 100% guaranteed method but is close.&lt;BR /&gt;&lt;BR /&gt;-Sri</description>
      <pubDate>Wed, 25 Feb 2004 18:40:20 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202538#M748677</guid>
      <dc:creator>Sridhar Bhaskarla</dc:creator>
      <dc:date>2004-02-25T18:40:20Z</dc:date>
    </item>
    <item>
      <title>Re: Forcing su rather than allowing telnet login for specific accounts</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202539#M748678</link>
      <description>In the /etc/passwd file, change the shell for the username/application to /bin/false.&lt;BR /&gt; &lt;BR /&gt;Thus users can ftp and su to that account, but if someone attempts to login it won't have a valid shell to start up.&lt;BR /&gt; &lt;BR /&gt;HTH&lt;BR /&gt; &lt;BR /&gt;-- Rod Hills</description>
      <pubDate>Wed, 25 Feb 2004 18:41:27 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202539#M748678</guid>
      <dc:creator>Rodney Hills</dc:creator>
      <dc:date>2004-02-25T18:41:27Z</dc:date>
    </item>
    <item>
      <title>Re: Forcing su rather than allowing telnet login for specific accounts</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202540#M748679</link>
      <description>I know one thing, I should learn how to read ... 8^)</description>
      <pubDate>Wed, 25 Feb 2004 19:04:48 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202540#M748679</guid>
      <dc:creator>Michael Tully</dc:creator>
      <dc:date>2004-02-25T19:04:48Z</dc:date>
    </item>
    <item>
      <title>Re: Forcing su rather than allowing telnet login for specific accounts</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202541#M748680</link>
      <description>I forgot about CDE logins. Users with Reflection X or Exceed can directly login to the systems with CDE. /etc/profile|csh.login won't help you in that case. You will need to place a X startup script with the same logic. For ex., Create a script called&lt;BR /&gt;&lt;BR /&gt;0000.directlogin under /etc/dt/config/Xsession.d with 555 permissions.&lt;BR /&gt;&lt;BR /&gt;Add the following shell into it&lt;BR /&gt;&lt;BR /&gt;grep -q "^${USER}:" /etc/nodirectlogin&lt;BR /&gt;if [ $? = 0 ]&lt;BR /&gt;then&lt;BR /&gt;/usr/dt/bin/dterror.ds "CDE login denied for $USER" "Login Denied" "Exit"&lt;BR /&gt;exit 1&lt;BR /&gt;fi&lt;BR /&gt;&lt;BR /&gt;This should disable all the users under /etc/nodirectlogin to logon via CDE.&lt;BR /&gt;&lt;BR /&gt;-Sri</description>
      <pubDate>Wed, 25 Feb 2004 19:08:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202541#M748680</guid>
      <dc:creator>Sridhar Bhaskarla</dc:creator>
      <dc:date>2004-02-25T19:08:38Z</dc:date>
    </item>
    <item>
      <title>Re: Forcing su rather than allowing telnet login for specific accounts</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202542#M748681</link>
      <description>Thanks for the suggestions. I'm going to try them out this weekend and get back with points next week.&lt;BR /&gt;&lt;BR /&gt;Please feel free to add to the list if you have any alternative ideas.</description>
      <pubDate>Thu, 26 Feb 2004 20:33:02 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202542#M748681</guid>
      <dc:creator>Jerry Anderson_5</dc:creator>
      <dc:date>2004-02-26T20:33:02Z</dc:date>
    </item>
    <item>
      <title>Re: Forcing su rather than allowing telnet login for specific accounts</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202543#M748682</link>
      <description>If you don't need specific settings from the user (so you don't run su - &lt;ACCOUNT&gt;, only su &lt;ACCOUNT&gt;, you could replace the contents of .profile to a single line: exit. This means the user will immediately be logged out when trying to login.&lt;BR /&gt;&lt;BR /&gt;If not, you could compare the first fields of 'who am i' and 'whoami'. If they are the same, the user needs to be logged out, so if you put that in the users .profile it should also work. The whoami info is updated after a su, while 'who am i' isn't. The line would become:&lt;BR /&gt;&lt;BR /&gt;if [ "`whoami`" = "`who am i | cut -d' ' -f1`" ]&lt;BR /&gt;then&lt;BR /&gt;    exit&lt;BR /&gt;fi&lt;BR /&gt;&lt;/ACCOUNT&gt;&lt;/ACCOUNT&gt;</description>
      <pubDate>Fri, 27 Feb 2004 04:18:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202543#M748682</guid>
      <dc:creator>Elmar P. Kolkman</dc:creator>
      <dc:date>2004-02-27T04:18:51Z</dc:date>
    </item>
    <item>
      <title>Re: Forcing su rather than allowing telnet login for specific accounts</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202544#M748683</link>
      <description>Jerry -&lt;BR /&gt; I just went through something similar. The developers need ftp access, but I have locked down replace and chmod in the ftpaccess file.&lt;BR /&gt;&lt;BR /&gt;Then there was a user I wanted to be able to ftp but not telnet.&lt;BR /&gt;&lt;BR /&gt;I simply test for username in /etc/profile at login, force them to exit and notify where it came from. The notify script gives me an ip address or pcname for which I can tract back to the user's work station.&lt;BR /&gt;&lt;BR /&gt;/etc/profile entry:&lt;BR /&gt;&lt;BR /&gt;# Exit if the user is jobdev                     &lt;BR /&gt;                                                 &lt;BR /&gt;        if test "$user" = "jobdev"               &lt;BR /&gt;        then                                     &lt;BR /&gt;        /usr/local/bin/systems/security/violator &lt;BR /&gt;        exit 0                                   &lt;BR /&gt;        fi                                       &lt;BR /&gt;&lt;BR /&gt;Notify script snippet:&lt;BR /&gt;# ============================================================&lt;BR /&gt;# Use the wtmp file to find the offender.&lt;BR /&gt;# ============================================================&lt;BR /&gt;&lt;BR /&gt;        last -R | head -1 | grep corp&lt;BR /&gt;                &lt;BR /&gt;        if [ $? -eq 0 ]&lt;BR /&gt;        then&lt;BR /&gt;        last -R | head -1 | mailx -s "MOE Login Violator" $MAIL_LIST&lt;BR /&gt;        else&lt;BR /&gt;        last -R | head -1 | awk '{ print $3 }' | cut -d ":" -f1 | read addr&lt;BR /&gt;        nslookup $addr | grep Name | cut -d ":" -f2 | read network_id&lt;BR /&gt;        echo "$addr on $network_id" | mailx -s "MOE Login Violator" \&lt;BR /&gt;        $MAIL_LIST&lt;BR /&gt;        fi&lt;BR /&gt;&lt;BR /&gt;Hope this assists a bit.&lt;BR /&gt;Best of luck.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;dl</description>
      <pubDate>Fri, 27 Feb 2004 19:44:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/forcing-su-rather-than-allowing-telnet-login-for-specific/m-p/3202544#M748683</guid>
      <dc:creator>Dave La Mar</dc:creator>
      <dc:date>2004-02-27T19:44:52Z</dc:date>
    </item>
  </channel>
</rss>

