I am planning to attend the July 1st SharePoint User Group meeting. It always well attended 50 to 150 people depending upon the evening. The meetings are the first Wednesday of the month at the Microsoft office in New York City.
http://www.sharepointusergroup.org/NewYork/default.aspx
Hope to see you there.
Wednesday, June 17, 2009
Tuesday, June 16, 2009
Renaming SQL Backup Files
If you use a SQL 2005 Maintenance Plan to create backups of individual databases, the .bak files have a date stamp on them. I have a customer that wants to handle the files with an automated tool and would prefer that the backup files have a consistent name. We could backup up the databases en masse, but we wanted separate backups for this purpose.
The solution was to create a VB script that runs as a scheduled task and renames the files every night after the backups are run. Here is the code that I wrote to handle renaming all of the files.
-------------------------------
The solution was to create a VB script that runs as a scheduled task and renames the files every night after the backups are run. Here is the code that I wrote to handle renaming all of the files.
-------------------------------
------------------------------------------
Note: this will fail in 2100. Just setting up some Y2100 work for your grandchildren.
Saturday, June 6, 2009
Active Directory Security Groups
Yesterday, during a Varonis training session, Paul Ezhaya started a great discussion by asking my opinion on strategies for naming security groups and organizing folders on file servers. The primary debate was whether to use security groups named after departments and roles or to use security groups named after folders that they provide access to. For example, if there was folder called Human Resources with sub-folders such as Employee Data, Forms, and Terminations, and folders specific to several departments how would we set this up from a security perspective? Would we create Active Directory groups based on Roles for the HR people who handle each department and then apply those groups to the corresponding folders on the file server? Or would we create AD groups named after the specific sub-folders and then add the specific people to those groups as needed? Along with the security groups we would take the lead in organizing the folder structure to match the security group naming conventions.
In general, I prefer the Folder-based solution. The first reason is for the long-term security of your organization. Finding the data is always top priority so regardless of how you organize the folders; users will learn the taxonomy and adjust to it. You need to force the organization to apply security; therefore, if you organize the infrastructure in a secure manner, they won’t have to. Second, When you first set up your Role-based Security Groups you might have an accurate grouping of the users by department. However, over time people will not make the appropriate adjustments to those groups. After the initial setup fades away, when you add someone to a role-based security group to they can access a particular set of data, you may not realize what else that gives them access to. You may not it even give it any consideration because security will always be an afterthought. In a Folder-based solution, the security of the data is pushed to the forefront as the IT department knows what folders the Active Directory group gives them access to. And if the access is insufficient user will surely let you know, where the odds of them notifying you that they were given too much access in the Role-based scenario is highly unlikely.
Of course, we may have a hybrid approach. At the top level shares we might want to have security groups for the department and apply those at that level. Then we would turn off inheritance on folders with confidential data and apply the folder-based security to those folders. So we end up with a set of groups like this:
grp_HumanResources
grp_Terminations-RO
grp_Terminations-RW
Where RO is for the group with Read Only privileges and RW is the group with Modify privileges.
If there are other reasons for you to use a Role-based strategy then I would highly recommend an automated Identify Access Management system. I think that you will still find that the default will be to provide too much access, but the results will be better.
In general, I prefer the Folder-based solution. The first reason is for the long-term security of your organization. Finding the data is always top priority so regardless of how you organize the folders; users will learn the taxonomy and adjust to it. You need to force the organization to apply security; therefore, if you organize the infrastructure in a secure manner, they won’t have to. Second, When you first set up your Role-based Security Groups you might have an accurate grouping of the users by department. However, over time people will not make the appropriate adjustments to those groups. After the initial setup fades away, when you add someone to a role-based security group to they can access a particular set of data, you may not realize what else that gives them access to. You may not it even give it any consideration because security will always be an afterthought. In a Folder-based solution, the security of the data is pushed to the forefront as the IT department knows what folders the Active Directory group gives them access to. And if the access is insufficient user will surely let you know, where the odds of them notifying you that they were given too much access in the Role-based scenario is highly unlikely.
Of course, we may have a hybrid approach. At the top level shares we might want to have security groups for the department and apply those at that level. Then we would turn off inheritance on folders with confidential data and apply the folder-based security to those folders. So we end up with a set of groups like this:
grp_HumanResources
grp_Terminations-RO
grp_Terminations-RW
Where RO is for the group with Read Only privileges and RW is the group with Modify privileges.
If there are other reasons for you to use a Role-based strategy then I would highly recommend an automated Identify Access Management system. I think that you will still find that the default will be to provide too much access, but the results will be better.
Subscribe to:
Posts (Atom)