| Erik's profileThe Creation of AdamBlogListsNetwork |  Tools  Help |
The Creation of Adam |
|||||||||||
|
April 22 The Creation of The Creation of AdamJudith, Jeff, and I were at the Dallas Windows 2008 Launch Event. We met up with Cameron, Trevor, and some others from Catapult Systems. Cameron asked me about the name "The Creation of Adam".
Truth to tell the origin is largely lost to antiquity, but a few of the derivations come to mind:
January 08 Apreso vs W3SVC vs Flash Media Service (FMS)Parker College of Chiropractic uses the Apreso application to record classroom audio. The Apreso server is shared by Flash Media Services, and this morning the Apreso Web Site would not start. It was giving us an error that the "file was already in use by another process". Through trial and error I isolated the problem to be the Flash Media Service (FMS) was stopping the Apreso Web Site from running. To aleviate the problem I decided to delay the loading of the FMS service until the World Wide Web service was loaded. To do this, I made FMS dependant on the W3Svc by adding the following REG_MULTI_SZ type key in the registry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FMS\DependOnService = W3SVC
"user cannot change password"I may have mentioned before, I work for a Parker College of Chiropractic in Dallas, Texas. Provisioning and Deprovisioning students, faculty and staff in our Microsoft domain enviroment is often times challenging, and definately can consume a great deal of time. One of our ongoing interests has been how to best handle employee terminations with a minimal amount of human involvement by the IS department; our current algorithm goes something like this:
· Change the Active Driectory (AD) User Object password to a random strong password. (This is simply to satisfy a deep seated paranoia) · Set the AD User Object expiration date to HR database termination date + 90 days. (This makes the default behavior to be account expiration, and gives IT personnel a way specify and postpone further disabling of the account) · Disable the AD User Object (This is good practice as there is at this moment no known reason to keep a terminated account active) · Set AD User Object property "User Cannot Change Password". (A random strong password has been set, and this will prevent any user from making a simple password that a disgruntled terminated employee might guess)
· Remove the AD User Object from all group memberships (This minimizes the Account security profile, and prevents bounce emails address to groups) · Remove the AD User Object from all Email Address Books (This minimizes questions about why the account remains active if the person has been terminated)
· M · Move the home drive to the administrative _RECYCLE_BIN (View this as a DELETE_ME staging area) · Set READ ONLY rights to the relocated home drive for Human Resources and the department security group (This prevents premature deletion of files, maintaining the file system in an unaltered state)
· Send an email to IT System Admins that the account has been disabled.
· · If the manager or HR choose to enable the account, they are directed to contact the Help Desk, and are encouraged and taught how to do the following in the initial direct report termination email: 1. The manager or delegate should log into OWA as the user and set an out of office agent that tells who the company contact is now. They can manage the message sent to internal and external contacts 2. Set forwarding rules to a new contact (available in owa after Exchange SP1) 3. Review and disposition existing emails 4. Review and copy existing files from the employee home drive to a new location · If the employee is terminated in the HR database and the expiration date is past, the account will be disabled (help desk may set the account disable time in active directory thus postponing deletion upon HR/manager request) · If the employee is terminated in the HR database and the account expiration date is 30 days past, and the last domain/email logon is 30 days past, 1. Ideally 1. the e-mail mailbox will deleted, 2. the home drive will be deleted, 2. alternatively 1. we can export the e-mail to a pst in the home drive file system (requires Exchange SP1) during the initial processing following termination 2. delete the e-mail mailbox 2. grant HR full permissions on the file system 3. So long as the send a weekly email to Human Resources that they should 1. burn the files to DVD 2. and file the DVD in the employee record 3. and delete the files 3. finally 1. All files on the shared departmental drive belonging to the user will be identified and ownership given to the department manager 2. the account will be moved to the DELETEME folder in Active Directory 3. An email will be sent to help desk that the account can be deleted from active directory When I began looking into ways to set the "user cannot change password" property of the User Object, it seemed that the simple approach would simply be to set the proper bit in the userAccountControl property of the object. Unfortunately this didn't work through powershell. There were many examples of it working in Visual Basic, I didn't want to do it that way. After a lot more research than the issue warranted, I found my two references:
http://msdn2.microsoft.com/en-us/library/aa746398.aspx
http://mow001.blogspot.com/2006/08/powershell-and-active-directory-part-8.html which together got me on the right track to solving the problem as provided below...
#########1#########2#########3#########4#########5#########6#########7#########8 #########0#########0#########0#########0#########0#########0#########0#########0 # # Author: Erik McCarty # # Description: Set the "user Cannot Change Password" property on an active # directory user object # # Remarks: There is poor documentation on the internet that would lead you # to believe the $user.userAccountControl property value bit 0x000040 can # be set to turn on the "user Cannot Change Password" account property. # However you cannot assign this permission by directly modifying the # userAccountControl attribute. # # History: # 20080107 EWM Initial Creation # # reference: # http://msdn2.microsoft.com/en-us/library/aa746398.aspx # http://mow001.blogspot.com/2006/08/powershell-and-active-directory-part-8.html # # Example: # # set-UserCannotChangePassword "BMcClellan" # #########1#########2#########3#########4#########5#########6#########7#########8 #########0#########0#########0#########0#########0#########0#########0#########0 # function set-UserCannotChangePassword( [string] $sAMAccountName ){ # set variables $everyOne = [System.Security.Principal.SecurityIdentifier]'S-1-1-0' $self = [System.Security.Principal.SecurityIdentifier]'S-1-5-10' $SelfDeny = new-object System.DirectoryServices.ActiveDirectoryAccessRule ($self,'ExtendedRight','Deny','ab721a53-1e2f-11d0-9819-00aa0040529b') $SelfAllow = new-object System.DirectoryServices.ActiveDirectoryAccessRule ($self,'ExtendedRight','Allow','ab721a53-1e2f-11d0-9819-00aa0040529b') $EveryoneDeny = new-object System.DirectoryServices.ActiveDirectoryAccessRule ($Everyone,'ExtendedRight','Deny','ab721a53-1e2f-11d0-9819-00aa0040529b') $EveryOneAllow = new-object System.DirectoryServices.ActiveDirectoryAccessRule ($Everyone,'ExtendedRight','Allow','ab721a53-1e2f-11d0-9819-00aa0040529b') # find the user object in the default domain # set "user cannot change password" #########1#########2#########3#########4#########5#########6#########7#########8
#########0#########0#########0#########0#########0#########0#########0#########0 # # Author: Erik McCarty # # Description: clear the "user Cannot Change Password" property on an active # directory user object # # Remarks: There is poor documentation on the internet that would lead you # to believe the $user.userAccountControl property value bit 0x000040 can # be set to turn on the "user Cannot Change Password" account property. # However you cannot assign this permission by directly modifying the # userAccountControl attribute. # # History: # 20080107 EWM Initial Creation # # reference: # http://msdn2.microsoft.com/en-us/library/aa746398.aspx # # Example: # # clear-UserCannotChangePassword "BMcClellan" # #########1#########2#########3#########4#########5#########6#########7#########8 #########0#########0#########0#########0#########0#########0#########0#########0 # function clear-UserCannotChangePassword( [string] $sAMAccountName ){ # set variables $everyOne = [System.Security.Principal.SecurityIdentifier]'S-1-1-0' $self = [System.Security.Principal.SecurityIdentifier]'S-1-5-10' $SelfDeny = new-object System.DirectoryServices.ActiveDirectoryAccessRule ($self,'ExtendedRight','Deny','ab721a53-1e2f-11d0-9819-00aa0040529b') $SelfAllow = new-object System.DirectoryServices.ActiveDirectoryAccessRule ($self,'ExtendedRight','Allow','ab721a53-1e2f-11d0-9819-00aa0040529b') $EveryoneDeny = new-object System.DirectoryServices.ActiveDirectoryAccessRule ($Everyone,'ExtendedRight','Deny','ab721a53-1e2f-11d0-9819-00aa0040529b') $EveryOneAllow = new-object System.DirectoryServices.ActiveDirectoryAccessRule ($Everyone,'ExtendedRight','Allow','ab721a53-1e2f-11d0-9819-00aa0040529b') # find the user object in the default domain
$searcher = New-Object DirectoryServices.DirectorySearcher $searcher.filter = "(&(samaccountname=$sAMAccountName))" $results = $searcher.findone() $user = $results.getdirectoryentry() # remove "user cannot change password"
$mr = $user.psbase.get_ObjectSecurity().GetAccessRules($true,$false, [System.Security.Principal.NTAccount]) |? {$_.ObjectType -eq 'ab721a53-1e2f-11d0-9819-00aa0040529b'} |? {$_.AccessControlType -eq 'Deny'} [void]$user.psbase.get_ObjectSecurity().RemoveAccessRule($mr[0]) [void]$user.psbase.get_ObjectSecurity().RemoveAccessRule($mr[1]) $user.psbase.CommitChanges() } December 05 Domain User Profile PathsSecuring user data in a network environment is important. We want to be able to access the files for helping the users, for backsups, and we want the user to be able to access them as needed. A network path works well, but keeping the security "right" isn't always simple. My objective here was to read over the T:\Users\ path, get the child directories which should match the user names, apply security and ownership.
I wish I had a more efficient way than iterating through all files and folders to set file ownership, but this was the best I've found so far.
#########1#########2#########3#########4#########5#########6#########7#########8
#########0#########0#########0#########0#########0#########0#########0#########0 # # Author: Erik McCarty # Description: on a file path, sets the owner of all child objects and # containers to the specified domain user. # # History: # 20071205 EWM Initial Creation # # Example: # $ID = "ewmccarty@domain" # $path = "\\domain\dfs\users\ewmccarty" # set-FileOwner $path $ID # #########1#########2#########3#########4#########5#########6#########7#########8 #########0#########0#########0#########0#########0#########0#########0#########0 function set-FileOwner { Param ( $path, $identity ) # convert the string domain username to a [System.Security.Principal.NTAccount] # which is derived from the required [System.Security.Principal.IdentityReference] $ID = new-object System.Security.Principal.NTAccount($Identity) # set owner on the path specified
$acl = get-acl $path $acl.SetOwner($ID) set-acl -path $path -aclObject $acl # set owner on the child folders and files
get-childitem -path $path -force -recurse | foreach { $longPath = $_.FullName write-progress -activity "Set File Owner" -status "Processing $longPath with user $ID" $acl = get-acl $_.fullname $acl.SetOwner($ID) set-acl -path $_.fullname -aclObject $acl } } #########1#########2#########3#########4#########5#########6#########7#########8
#########0#########0#########0#########0#########0#########0#########0#########0 # # Author: Erik McCarty # # Description: (1) Grants FullControl to domain admins and Information Services # Helpdesk personnel using an SDDL string copied from a # test database (this was easier and quicker than trying to figure # out how to cancel rights inheritance, as I just over write) # (2) Sets the File System rights to the user by the same name # as the child path, typically a user profile path. # (3) on a file path, sets the owner of all child objects and # containers to the specified domain user. # # History: # 20071205 EWM Initial Creation # # Example: # $path = "\\domain\DFS\Users" # $path = "\\domain\DFS\Users\_test" # $domain = "domain" # set-FileSystemSecurity $path $domain # # references: # http://www.vistax64.com/powershell/30696-changing-file-ownership-powershell-way-anyone.html # http://thepowershellguy.com/blogs/posh/archive/tags/Active+Directory/default.aspx # http://dmitrysotnikov.wordpress.com/2007/07/25/set-any-ad-attribute-with-powershell/ # http://mow001.blogspot.com/2005/10/update-typedata-democracy-to-types.html # http://mow001.blogspot.com/2005/10/msh-takeowner-working.html # http://mow001.blogspot.com/2005/10/update-typedata-democracy-to-types.html # http://msdn2.microsoft.com/en-us/library/system.security.accesscontrol.filesystemrights.aspx # http://msdn2.microsoft.com/en-us/library/system.security.accesscontrol.inheritanceflags.aspx # # notes: # [System.Security.AccessControl.FileSystemRights]::AppendData # Specifies the right to append data to the end of a file. # [System.Security.AccessControl.FileSystemRights]::ChangePermissions # Specifies the right to change the security and audit rules associated with a file or folder. # [System.Security.AccessControl.FileSystemRights]::CreateDirectories # Specifies the right to create a folder. This right requires the Synchronize value. Note that if you do not explicitly set the Synchronize value when creating a file or folder, the Synchronize value will be set automatically for you. # [System.Security.AccessControl.FileSystemRights]::CreateFiles # Specifies the right to create a file. This right requires the Synchronize value. Note that if you do not explicitly set the Synchronize value when creating a file or folder, the Synchronize value will be set automatically for you. # [System.Security.AccessControl.FileSystemRights]::Delete # Specifies the right to delete a folder or file. # [System.Security.AccessControl.FileSystemRights]::DeleteSubdirectoriesAndFiles # Specifies the right to delete a folder and any files contained within that folder. # [System.Security.AccessControl.FileSystemRights]::ExecuteFile # Specifies the right to run an application file. # [System.Security.AccessControl.FileSystemRights]::FullControl # Specifies the right to exert full control over a folder or file, and to modify access control and audit rules. This value represents the right to do anything with a file and is the combination of all rights in this enumeration. # [System.Security.AccessControl.FileSystemRights]::ListDirectory # Specifies the right to read the contents of a directory. # [System.Security.AccessControl.FileSystemRights]::Modify # Specifies the right to read, write, list folder contents, delete folders and files, and run application files. This right includes the ReadAndExecute right, the Write right, and the Delete right. # [System.Security.AccessControl.FileSystemRights]::Read # Specifies the right to open and copy folders or files as read-only. This right includes the ReadData right, ReadExtendedAttributes right, ReadAttributes right, and ReadPermissions right. # [System.Security.AccessControl.FileSystemRights]::ReadAndExecute # Specifies the right to open and copy folders or files as read-only, and to run application files. This right includes the Read right and the ExecuteFile right. # [System.Security.AccessControl.FileSystemRights]::ReadAttributes # Specifies the right to open and copy file system attributes from a folder or file. For example, this value specifies the right to view the file creation or modified date. This does not include the right to read data, extended file system attributes, or access and audit rules. # [System.Security.AccessControl.FileSystemRights]::ReadData # Specifies the right to open and copy a file or folder. This does not include the right to read file system attributes, extended file system attributes, or access and audit rules. # [System.Security.AccessControl.FileSystemRights]::ReadExtendedAttributes # Specifies the right to open and copy extended file system attributes from a folder or file. For example, this value specifies the right to view author and content information. This does not include the right to read data, file system attributes, or access and audit rules. # [System.Security.AccessControl.FileSystemRights]::ReadPermissions # Specifies the right to open and copy access and audit rules from a folder or file. This does not include the right to read data, file system attributes, and extended file system attributes. # [System.Security.AccessControl.FileSystemRights]::Synchronize # Specifies whether the application can wait for a file handle to synchronize with the completion of an I/O operation. The Synchronize value is automatically set when allowing access, and automatically excluded when denying access. The right to create a file or folder requires this value. Note that if you do not explicitly set this value when creating a file, the value will be set automatically for you. # [System.Security.AccessControl.FileSystemRights]::TakeOwnership # Specifies the right to change the owner of a folder or file. Note that owners of a resource have full access to that resource. # [System.Security.AccessControl.FileSystemRights]::Traverse # Specifies the right to list the contents of a folder and to run applications contained within that folder. # [System.Security.AccessControl.FileSystemRights]::Write # Specifies the right to create folders and files, and to add or remove data from files. This right includes the WriteData right, AppendData right, WriteExtendedAttributes right, and WriteAttributes right. # [System.Security.AccessControl.FileSystemRights]::WriteAttributes # Specifies the right to open and write file system attributes to a folder or file. This does not include the ability to write data, extended attributes, or access and audit rules. # [System.Security.AccessControl.FileSystemRights]::WriteData # Specifies the right to open and write to a file or folder. This does not include the right to open and write file system attributes, extended file system attributes, or access and audit rules. # [System.Security.AccessControl.FileSystemRights]::WriteExtendedAttributes # Specifies the right to open and write extended file system attributes to a folder or file. This does not include the ability to write data, attributes, or access and audit rules. # # [System.Security.AccessControl.InheritanceFlags]::ContainerInherit # The ACE is inherited by child container objects. # [System.Security.AccessControl.InheritanceFlags]::ObjectInherit # The ACE is inherited by child leaf objects. # [System.Security.AccessControl.InheritanceFlags]::None # The ACE is not inherited by child objects. # # [System.Security.AccessControl.PropagationFlags]::InheritOnly # Specifies that the ACE is propagated only to child objects. This includes both container and leaf child objects. # [System.Security.AccessControl.PropagationFlags]::NoPropagateInherit # Specifies that the ACE is not propagated to child objects. # [System.Security.AccessControl.PropagationFlags]::None #########1#########2#########3#########4#########5#########6#########7#########8 #########0#########0#########0#########0#########0#########0#########0#########0 function set-FileSystemSecurity
{ Param ( $path, $domain ) $DSIdentity = "Getting Started" get-childitem -path $path -force | where { $_.PSIsContainer } | foreach { trap { "Error processing path $path for user $DSIdentity" } $DSIdentity = "$_`@$domain"
$path = $_.FullName $acl = get-acl $path
# this value was determined empirically by setting up the security manually, then
# executing {get-acl $path}.sddl and copying the value into this script # Set the access rights for the "PARKERNET\Domain Admins" to FullControl # Set the access rights for the "STU-PARKERNET\Domain Admins" to FullControl # Set the access rights for the "PARKERNET\DS_DEPT_IS_Help" to FullControl $acl.SetSecurityDescriptorSddlForm("O:BAG:DUD:PAI(A;OICI;FA;;;S-1-5-21-3696674658-157342442-1474404594-512)(A;OICI;FA;;;DA)(A;OICI;FA;;;S-1-5-21-484763869-562591055-1547161642-4439)") "Processing path $path for user $DSIdentity "
$ID = new-object System.Security.Principal.NTAccount($DSIdentity) write-progress -activity "Profile Paths" -status "$path $DSIdentity"
# Set the access rights for the domain user whose SAM is the same as the Directory
# He can modify all child containers and files $Rights = [System.Security.AccessControl.FileSystemRights]::FullControl $Inherit = [System.Security.AccessControl.InheritanceFlags] "ContainerInherit, ObjectInherit" $Prop = [System.Security.AccessControl.PropagationFlags]::InheritOnly # set AccessControlType : Allow / Deny
$Access = [System.Security.AccessControl.AccessControlType]::Allow # create new access rule $AccessRule = new-object System.Security.AccessControl.FileSystemAccessRule($ID,$Rights,$Inherit,$Prop,$Access) # validate access rule $Sid = $AccessRule.IdentityReference.Translate([System.Security.Principal.securityidentifier]) $acl.AddAccessRule($AccessRule) # save the acl modifications to the path set-acl -path $path -aclObject $acl # set file ownership on the path and the child folders and files set-FileOwner $path $ID } } October 23 Multiple content data items within a single content blockParker College of Chiropractic (www.ParkerCC.edu) began using Ektron CMS 400 (www.Ektron.com) in the summer of 2006, with the first site going live 1 Sept 2006. Learing how best to use it has been a bit of a moving target, but it is a very nice CMS for being the only one I've ever used. One of the challenges has been minimizing the number of templates while at the same time taking advantage of the power of the CMS itself. The following techniques seems now to be the best approach to presenting multiple Content Data items in a single Content Block. (I've touched up this code to genericize it somewhat, and make it shorter for blogging. I've not actually tested it in its current state. If it has errors feel free to let me know and I'll make correction if needed) Here is a simple master page. The codefile "Supporting.master.cs" has nothing added to it. <%@ Master Language="C#" AutoEventWireup="true" CodeFile="Supporting.master.cs" Inherits="Supporting" %> Here is the corresponding template page, Supporting.aspx, making use of the ContentBlock tag <%@ Page Language="C#" MasterPageFile="~/Masters/Supporting.master" AutoEventWireup="true" CodeFile="Supporting.aspx.cs" Inherits="Masters_Default" Title="Untitled Page" %> Here is the template page code behind in a file named Supporting.aspx.cs. Note that I've added a METADATA to called "Subsequent_Content" of type CONTENT and assigned it to the root of my EKTRON CMS CONTENT FOLDERS. This template will when access via a url such as http://www.mydomain.com/Supporting.aspx?id=23 have the effect of displaying content data with content_id=23. Furthermore, if content data items 27 and 25 are added to the "Subsequent_Content" METADATA of content data 23, then the template will display items 23, 27, and 25 in that order; allowing for the display of multiple content data items on a single page as if a single article.
using System; public partial class Masters_Default : System.Web.UI.Page{ Why not just put them all a single content item?
|
|
|||||||||
|
|
