Windows NTFS app server security for a Unix-to-Windows conversion

 7 Replies
 0 Subscribed to this topic
 15 Subscribed to this forum
Sort:
Author
Messages
George
Basic Member
Posts: 5
Basic Member
    Hi.
    New to this LawsonGuru forum, newbie to Lawson (been around a long while doing Windows server admin). I am not a Unix admin. Our organization is converting from Unix/Oracle Lawson S3 (LSF v9.x) to Windows2008R2/MsSQLserver (LSF v9.x). Having some issues with proper NTFS security. Microsoft Subsystem for Unix Applications (Ms-SUA) is, of course, installed as a Windows Server role for our Lawson application server. Been reading up on mapping Unix to NTFS permissions. And as a Windows administrator have some best practices in mind (least permissions assigned). Can't seem to find Lawson-inspired or authored file system documentation, so need help determining what base permissions should be assigned for the Lawson servers' disk volumes.

    So... any recommendations for some light reading to implement Microsoft Windows security best practices for our Lawson environment? We have immediate need to get the Unix-to-Windows permissions understood and set.

    Thank you.

    P.S. Besides the LSF application server (prime focus here), we also have separate AD LDS (Adam), LBI, LBP, MSCM, Punchout, EDI and separate Ms-SQL servers, but they are another discussion.
    Kwane McNeal
    Veteran Member
    Posts: 479
    Veteran Member
      George,
      I did a substantial amount of work in this area on Windows NT4, Windows 200, and Windows 2003. I have just begun to do more formal work on this on Windows 2008 family of OS, so I would be willing to share what I have so far, as well as my understanding of what's there.

      Lawson has historically never committed to specifics in this area, save what is needed to ensure basic application functionality. I actually agree with their approach on this, due to their development methodolgies.

      Feel free to call me on this, off list, at the number below
      I am working on a few things for the next few days, so if I'm not able to answer immediately, leave me a vmail or a PM here, and I'll call you back as quickly as I am able.

      Kwane
      505-433-RSGI
      George
      Basic Member
      Posts: 5
      Basic Member

        Adding clarity to my original question in hopes this will spark some discusson on this thread. Thank you in advance...

        Because Unix (Microsoft Subsystem for Unix Applications, SUA) permission bits are limited to a “owner”, “group”, “world” paradigm, and there is no direct comparable Windows NTFS security setup, it is impossible to derive a Windows security model from the Unix settings. (Note that it is possible to translate security in the other direction: Windows NTFS security can be “simplified” and expressed as SUA permission bits - but that is not the problem I need to solve.)

         

        As I understand things, Lawson installs on top of “default” Microsoft Windows file system security permission settings. It appears that additional file system security is applied onto selected directories within the Lawson application folder structure, implemented as Unix permission bits in the scripts provided by Lawson. However due to the limited nature of SUA permission bits, the result is not an effective control of file system security.

         

        Windows by default allows read access to all domain users for most files. Lawson SUA permission bits settings are overlaid on top of the default Microsoft permissions without removing the default. Therefore having limited effect.

         

        Best Practices:

        ·         tighten up security by default (initially provide no access to the Lawson files and folders)

        ·         as specific requirements are identified, provide access

        ·         appropriate (multiple) Active Directory global security groups would be created and used to document the needed access

         

        To implement the best practices I need to know security requirements for

        ·         users

        ·         services

        ·         which folders/files  

         

         

        I hope the above is helpful in getting the right documentation and recommendations from Lawson. Thank you.

        Jimmy Chiu
        Veteran Member
        Posts: 641
        Veteran Member
          Have you looked into using permsmaint? I use that to manage my NTFS files permission for lawson related files/folders.
          George
          Basic Member
          Posts: 5
          Basic Member
            Yes, looked at Permsmaint. Problem with it is that it was developed for a Unix host rather than a Windows domain. So, after some thought on this we are turning the Microsoft best practice on its head - opting instead for locking down SHARE security and leaving NTFS folder security setting as Lawson delivers it in  permsmaint (pretty much unsecured). This is not perfect, but will get the job done given our urgent deadlines.

            We have 500+ Windows servers and a standard practice for securing and providing access to them. The new Lawson Windows servers don't fit into established practices. Given the nature of the data this is surprising to me. So I hoped this Unix-to-Windows question had already been solved. Lawson is, of course, no help.
            Jimmy Chiu
            Veteran Member
            Posts: 641
            Veteran Member
              It seems to me that you are trying to lock down security via microsoft NTFS file permissions. But that's just one of the available tools(and not enough i may add) to lockdown security with lawson users. In my opinion, properly designed LS roles + refined ladirs.cfg (permsmaint), along with your security level during install would be sufficent to lock out non-admin, non-developer access to the folders/files.

              For my typical users who are on LS security, I can't think of a way for them to have direct access to Lawson files/folders.

              I would highly suggest you get yourself familiar with Lawson Security Administration before spending too much time on configuring NTFS permissions.

              George
              Basic Member
              Posts: 5
              Basic Member
                Thanks for replying Jimmy. Lawson users, as you say, can't get into the file system directly. They are not my concern. The non-Lawson users are, however.

                Since the Lawson Windows servers do not exist in a vacuum - they share a network with 500+ other Windows servers and thousands of other Microsoft computers - I am trying to take appropriate minimal steps. Inappropriate users, malware, and "hackers" do not care about Lawson security because they can take advantage of poor system configuration practices or system bugs. The file system which uses Microsoft security defaults is not secure. It would only take a new SMB security hole (and there have been several in 2011) to allow the riff-raff in...

                How do you interface to other systems in your network (do you have CIFS shares on your Windows servers)?
                My work-around is to set up secure Windows share security so I am preventing domain users from casually browsing to the CIFS shares on the Lawson servers and finding raw Lawson data. It's something.

                Thanks!
                Jimmy Chiu
                Veteran Member
                Posts: 641
                Veteran Member
                  Posted By George on 05/25/2011 09:40 AM

                  Windows by default allows read access to all domain users for most files. Lawson SUA permission bits settings are overlaid on top of the default Microsoft permissions without removing the default. Therefore having limited effect.


                  I am not sure if this is what you meant. See screenshot:



                  This is a my NTFS permission for my %LAWDIR%\gen folder on my test server.

                  SYSTEM
                  Lawdev <-- my lawson developer users group
                  LawLocal  <--- my lawson users group
                  Administrators

                  - The default windows permissions were removed by permsmaint.
                  - The above permisisons were reapplied by permsmaint
                  - Default local/windows users group has no access right to these folders/files processed by permsmaint

                  Am I missing something?