<?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: Updating  protected password database in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/updating-protected-password-database/m-p/4020388#M299941</link>
    <description>So what you're saying is that if the field doesn't exist, we need to set both to get it to work, correct?</description>
    <pubDate>Thu, 14 Jun 2007 14:20:09 GMT</pubDate>
    <dc:creator>Jim Poplawski</dc:creator>
    <dc:date>2007-06-14T14:20:09Z</dc:date>
    <item>
      <title>Updating  protected password database</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/updating-protected-password-database/m-p/4020385#M299938</link>
      <description>Folks,&lt;BR /&gt;We have an HPUX application that talks to our custom workstation application to get the userid/password.  the program then checks the password by encrypting it and comparing the encrypted string to that of the encrpyted password stored on the server. The user does not do an actual login to HPUX.  That works fine.  &lt;BR /&gt;  We need to update the functionality so that we can lock the account after the required number of bad attempts.  &lt;BR /&gt;  So…we've written a test program that reads protected password stuff using the getprpwent() system call.  The program then increments the fd_nlogins counter and writes the entire entry back using the putprpwnam system call.  This does not work, the retry count is not udpated. To insure that the program is not "flakey" I revised it to update the fd_max_tries counter and it works fine.&lt;BR /&gt;Any ideas why the fd_nlogins counter wouldn't update?&lt;BR /&gt;thanks!&lt;BR /&gt;Jim &lt;BR /&gt;</description>
      <pubDate>Thu, 14 Jun 2007 12:56:03 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/updating-protected-password-database/m-p/4020385#M299938</guid>
      <dc:creator>Jim Poplawski</dc:creator>
      <dc:date>2007-06-14T12:56:03Z</dc:date>
    </item>
    <item>
      <title>Re: Updating  protected password database</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/updating-protected-password-database/m-p/4020386#M299939</link>
      <description>Can you past the line of code that updates fd_nlogins?</description>
      <pubDate>Thu, 14 Jun 2007 14:03:48 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/updating-protected-password-database/m-p/4020386#M299939</guid>
      <dc:creator>Court Campbell</dc:creator>
      <dc:date>2007-06-14T14:03:48Z</dc:date>
    </item>
    <item>
      <title>Re: Updating  protected password database</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/updating-protected-password-database/m-p/4020387#M299940</link>
      <description>I had to go look in my comments of some code I have that makes calls to putprpwnam() and I did find exactly your behavior when trying to reset fd_nlogins. The call would return a non-zero result (which for some whackball reason means ok in sharp contrast to almost all functions) but the fd_nlogins value would be unchanged. There was a wrinkle. If the field, u_numunsuclog#N, in the actual tcb files was present THEN the value would be updated. However, if the field was not already in the file (which is the default if there have been no bad logins) then the value would not be written to the file.</description>
      <pubDate>Thu, 14 Jun 2007 14:17:50 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/updating-protected-password-database/m-p/4020387#M299940</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2007-06-14T14:17:50Z</dc:date>
    </item>
    <item>
      <title>Re: Updating  protected password database</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/updating-protected-password-database/m-p/4020388#M299941</link>
      <description>So what you're saying is that if the field doesn't exist, we need to set both to get it to work, correct?</description>
      <pubDate>Thu, 14 Jun 2007 14:20:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/updating-protected-password-database/m-p/4020388#M299941</guid>
      <dc:creator>Jim Poplawski</dc:creator>
      <dc:date>2007-06-14T14:20:09Z</dc:date>
    </item>
    <item>
      <title>Re: Updating  protected password database</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/updating-protected-password-database/m-p/4020389#M299942</link>
      <description>I don't know what you mean by "both". The field "u_numunsuclog#count" in the /tcb/file/auth/x/xusername corresponds to the fd_nlogins inside a pr_field struct.&lt;BR /&gt;&lt;BR /&gt;Start by manually inserting "u_numunsuclog#0" into the file to set the value at zero and see if your routine doesn't then work as expected. Your final version will probably have to invoke sed, Perl, or some really ugly C to parse this entry and insert the needed field.&lt;BR /&gt;&lt;BR /&gt;You should note that this is one of the fields that the modprpw command does not allow to be updated so there appears to be some method to this madness.</description>
      <pubDate>Thu, 14 Jun 2007 14:34:56 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/updating-protected-password-database/m-p/4020389#M299942</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2007-06-14T14:34:56Z</dc:date>
    </item>
  </channel>
</rss>

