<?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: Update internal password with a stored process in Administration and Deployment</title>
    <link>https://communities.sas.com/t5/Administration-and-Deployment/Update-internal-password-with-a-stored-process/m-p/931389#M28590</link>
    <description>&lt;P&gt;I'm not an admin or a security guy, but this seems risky.&amp;nbsp; If you write a stored process to hand-roll the process of updating passwords, you could easily end up with passwords ending up in clear text log files, etc.&amp;nbsp;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I assumed most servers were set up to integrate with an independent, dedicated account/password management system (e.g. active directory on Windows), where I would assume any processes for updating passwords would be secure by design.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;(Oh, I just googled.&amp;nbsp; The definition of these internal accounts (@saspw) is that they exist only in metadata, not in an external authentication domain. So I can how if you've got a lot of these, you would want some automated way for users to be able to maintain them.&amp;nbsp; yikes. Assuming these users only have read access to reports that aren't sensitive, maybe the benefits of having an automated stored process to allow users to manage their passwords are worth the security risks.)&lt;/P&gt;</description>
    <pubDate>Sat, 08 Jun 2024 14:32:53 GMT</pubDate>
    <dc:creator>Quentin</dc:creator>
    <dc:date>2024-06-08T14:32:53Z</dc:date>
    <item>
      <title>Update internal password with a stored process</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Update-internal-password-with-a-stored-process/m-p/931380#M28589</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;I have a large set of users (internal users @saspw)&amp;nbsp;and I'd like to give them the chance to change their internal password by themselves.&lt;/P&gt;&lt;P&gt;They have an access to the stored process web app, and only that application.&lt;/P&gt;&lt;P&gt;I am thinking of a Stored Process that they could use to change this password.&lt;/P&gt;&lt;P&gt;Has someone already created such stored process?&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;Cédric&lt;/P&gt;</description>
      <pubDate>Sat, 08 Jun 2024 07:55:57 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Update-internal-password-with-a-stored-process/m-p/931380#M28589</guid>
      <dc:creator>Cedric_HANQUEZ</dc:creator>
      <dc:date>2024-06-08T07:55:57Z</dc:date>
    </item>
    <item>
      <title>Re: Update internal password with a stored process</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Update-internal-password-with-a-stored-process/m-p/931389#M28590</link>
      <description>&lt;P&gt;I'm not an admin or a security guy, but this seems risky.&amp;nbsp; If you write a stored process to hand-roll the process of updating passwords, you could easily end up with passwords ending up in clear text log files, etc.&amp;nbsp;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I assumed most servers were set up to integrate with an independent, dedicated account/password management system (e.g. active directory on Windows), where I would assume any processes for updating passwords would be secure by design.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;(Oh, I just googled.&amp;nbsp; The definition of these internal accounts (@saspw) is that they exist only in metadata, not in an external authentication domain. So I can how if you've got a lot of these, you would want some automated way for users to be able to maintain them.&amp;nbsp; yikes. Assuming these users only have read access to reports that aren't sensitive, maybe the benefits of having an automated stored process to allow users to manage their passwords are worth the security risks.)&lt;/P&gt;</description>
      <pubDate>Sat, 08 Jun 2024 14:32:53 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Update-internal-password-with-a-stored-process/m-p/931389#M28590</guid>
      <dc:creator>Quentin</dc:creator>
      <dc:date>2024-06-08T14:32:53Z</dc:date>
    </item>
    <item>
      <title>Re: Update internal password with a stored process</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Update-internal-password-with-a-stored-process/m-p/931486#M28592</link>
      <description>&lt;P&gt;There's a large learning curve to doing this if you haven't played with SAS metadata before. You will need to become familiar with the &lt;A href="https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/lrmeta/part-5.htm" target="_blank" rel="noopener"&gt;DATA step metadata functions&lt;/A&gt;. then learn how to navigate the metadata object model. I find it easiest to use the metadata browser (&lt;A href="https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/lrmeta/p1sx3unuqtoykbn141wrhpcj3n1t.htm" target="_blank" rel="noopener"&gt;METABROWSE&lt;/A&gt;) that is available in the SAS Windowing Environment. Please note that writing to the SAS metadata repository is risky and can easily end up corrupting it. You could investigate the Active Directory metadata synching process to gain a better understanding of updating.&lt;/P&gt;</description>
      <pubDate>Mon, 10 Jun 2024 06:10:16 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Update-internal-password-with-a-stored-process/m-p/931486#M28592</guid>
      <dc:creator>SASKiwi</dc:creator>
      <dc:date>2024-06-10T06:10:16Z</dc:date>
    </item>
  </channel>
</rss>

