home *** CD-ROM | disk | FTP | other *** search
/ Tricks of the Windows Gam…ming Gurus (2nd Edition) / Disc2.iso / msdn_vcb / samples / vc98 / sdk / winbase / security / winnt / check_sd / readme.txt < prev    next >
Encoding:
Text File  |  1996-04-19  |  3.0 KB  |  81 lines
  1. Check Security Descriptors (SD)
  2.  
  3.  
  4. In the Win32 Programmer's Reference, if you go to the Security overview, then
  5. choose the sub-topic "Allowing Access", you'll find the comment
  6.  
  7.    Note: It is fine to write code like this that builds security
  8.    descriptors from scratch. It is, however, a good practice
  9.    for people who write code that builds or manipulates
  10.    security descriptors to first write code that explores the
  11.    default security descriptors that Windows NT places on
  12.    objects. For example, if Windows NT by default includes in
  13.    a DACL an ACE granting the Local Logon SID certain access,
  14.    it's good to know that, so that a decision not to grant any
  15.    access to the Local Logon SID would be a conscious decision
  16.  
  17. This comment is accurate, however, to begin with, this task of examining the
  18. SD is easier if there is sample code to start from. The purpose of the CHECK_SD
  19. sample is to provide sample code you can start from as you examine an SD.
  20. This sample only examines the SD on files, but the code can be modified to
  21. examine the SD on other objects.
  22.  
  23. This sample is not a supported utility
  24.  
  25. To run
  26. ------
  27.  
  28. Type Check_sd to check the SD on the \\.\A: device
  29.  
  30.    Type Check_sd d:\a.fil to check the SD on the d:\a.fil
  31.       file.  In this case d: must be formatted NTFS,
  32.       because only NTFS files have SD(s)
  33.  
  34. Further notes
  35. -------------
  36.  
  37. If you recompile with this define statement included:
  38.  
  39.   #define I_DO_NOT_WANT_THIS_CODE_TO_CLUTTER_THIS_PROGRAM_S_OUTPUT (1==0)
  40.  
  41. and re-run the program, the program will display more output, including
  42. all the information you can access from the process Access Token, and the
  43. SD's of some sample objects.
  44.  
  45. If you logon, run with the program built to produce the extra output as
  46. mentioned, save that output to a file, log off and re-run the program,
  47. and save the output of this second run to a different file, then you use
  48. WinDiff to observe how the local logon SID changes values for each session.
  49.  
  50. Here is a sample test you could run to exercise DACLs involves using the
  51. SD_FLPPY sample in conjunction with the CHECK_SD sample:
  52.  
  53.  - Log on to a machine as a local Administrator
  54.  - Do
  55.       check_sd \\.\A: >out_bef.a
  56.       check_sd \\.\B: >out_bef.b
  57.  - Logoff
  58.  - Log on the same machine as Guest on the local machine domain
  59.  - Do
  60.       sd_flppy
  61.  - Try
  62.       dir a:    (observe access denied)
  63.       dir b:    (observe access denied)
  64.       copy config.sys a:\   (get device not found)
  65.       copy config.sys b:\   (get device not found)
  66.  - Logoff
  67.  - Log on the same machine as a local Administrator
  68.  - Do
  69.       check_sd \\.\A: >out_aft.a
  70.       check_sd \\.\B: >out_aft.b
  71.  - Browse the differences between out_bef.* and out_aft.*
  72.  
  73. This test demonstrates that the ACLs that SD_FLPPY applies survive logoff.
  74. To demonstrate that the DACLs do not survive logoff, simply reboot, log back
  75. on as a local Administrator, and run the commands:
  76.  
  77.    check_sd \\.\A: >out_rbt.a
  78.    check_sd \\.\B: >out_rbt.b
  79.  
  80. to see the DACLs are again as they were.
  81.