<?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: Current New Security Directives on WIN in Administration and Deployment</title>
    <link>https://communities.sas.com/t5/Administration-and-Deployment/Current-New-Security-Directives-on-WIN/m-p/975620#M30310</link>
    <description>&lt;P&gt;In my experience, most SAS service accounts don't need the RDP permission, that is the ability to logon to SAS servers via Windows remote desktop connections. The one obvious exception to this is the SAS install account. Some service accounts may need the remote login permission but that isn't the same as RDP. So in general I would see no need to change service accounts and it should be fine to remove their RDP permissions. I suggest you check with Tech Support though for a second opinion.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Typically I use my own personal account for general SAS adminstration, as it has the RDP permssion and server admin permissions. That means it is fine for most housekeeping activities, including stopping and starting SAS services. I use the SAS install account when applying SAS maintenance.&lt;/P&gt;</description>
    <pubDate>Wed, 24 Sep 2025 02:09:29 GMT</pubDate>
    <dc:creator>SASKiwi</dc:creator>
    <dc:date>2025-09-24T02:09:29Z</dc:date>
    <item>
      <title>Current New Security Directives on WIN</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Current-New-Security-Directives-on-WIN/m-p/975617#M30309</link>
      <description>&lt;P&gt;Organization are now clamping on service IDs having the ability to RDP, usually it is a common directive to use installing IDs for hot fix, UIP etc. type of activities.&amp;nbsp; For routine matters, especially on WIN platforms one could use an admin ID to start stop services, etc. but how have you folks dealt with UIP or hot fix application when security won't allow these SAS service IDs to remote login?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;#2 Has anyone replaced the original SAS service IDs (svc_install, svc_sasdemo, svc_sassrv) by some IDs that do not have svc attached (for UIP/HF type tasks)? Pitfalls?&lt;/P&gt;</description>
      <pubDate>Tue, 23 Sep 2025 22:01:52 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Current-New-Security-Directives-on-WIN/m-p/975617#M30309</guid>
      <dc:creator>shoin</dc:creator>
      <dc:date>2025-09-23T22:01:52Z</dc:date>
    </item>
    <item>
      <title>Re: Current New Security Directives on WIN</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Current-New-Security-Directives-on-WIN/m-p/975620#M30310</link>
      <description>&lt;P&gt;In my experience, most SAS service accounts don't need the RDP permission, that is the ability to logon to SAS servers via Windows remote desktop connections. The one obvious exception to this is the SAS install account. Some service accounts may need the remote login permission but that isn't the same as RDP. So in general I would see no need to change service accounts and it should be fine to remove their RDP permissions. I suggest you check with Tech Support though for a second opinion.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Typically I use my own personal account for general SAS adminstration, as it has the RDP permssion and server admin permissions. That means it is fine for most housekeeping activities, including stopping and starting SAS services. I use the SAS install account when applying SAS maintenance.&lt;/P&gt;</description>
      <pubDate>Wed, 24 Sep 2025 02:09:29 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Current-New-Security-Directives-on-WIN/m-p/975620#M30310</guid>
      <dc:creator>SASKiwi</dc:creator>
      <dc:date>2025-09-24T02:09:29Z</dc:date>
    </item>
  </channel>
</rss>

