Welcome to Kraft Kennedy

WSS does not have a user profile service and does not allow any kind of native targeting of content to users in different groups. This is one of the more serious limitations of WSS, especially for corporate intranets, where pages might need to be customized for users in different offices. MOSS, on the other hand, allows for the creation of audiences and easy targeting of content. As is typically the case with WSS, it is possible to achieve this functionality by writing code.

One way to do this is by adding a reference in your code to “System.DirectoryServices,” which allows you to query Active Directory. With that class, you can compare the current user to an Active Directory group’s membership collection, and add logic based on whether or not the user is in the group. If you plan to edit an aspx page directly, you will also have to add a page parser path in web.config, so that the code in the page will run. Rather than editing the page directly, it is often preferable to create a control or web part for security and manageability reasons.

If editing an aspg page directly in SharePoint Designer, just add the following line to the top of the page, so that the correct assembly is referenced.

<%@ Assembly Name="System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" %>

Then add a code block into the page that gets the current user and compares it to the group membership. The following example uses VB.Net and sees if the current user is in the “NY Staff” group. If so, then the script redirects to the page “NY.aspx.” Rather than redirecting, you could also add code to write out customized content based on the membership information.

               <%

    Try
   'Get group membership for current user
        Dim DomainUser As String = Replace(User.Identity.Name, "\", "/")
        Dim ADEntry As New System.DirectoryServices.DirectoryEntry("WinNT://" & DomainUser)
        Dim MembersCollection As Object 'Underlaying is a IADsMembers interface
        MembersCollection = ADEntry.Invoke("Groups")
        Dim group As Object 'IADsGroup interface
        Dim vFound As Boolean = False
        For Each group In MembersCollection
            If LCase(group.Name) = "ny staff" Then
                vFound = True
                Exit For
            End If
        Next
        'Do something if group is found
        If vFound Then
            Response.redirect("NY.aspx")
        End If
      Catch ex As Exception
        'response.write(ex.message)
      End Try
%>

When managing a VMware ESX host, most functions can be done via the VI Client. The VI Client offers an easy to use GUI interface for management and configuration of one or multiple ESX hosts. That said, there are times when connecting to the Service Console of the ESX host is required. Often times multiple administrators will login to the Service Console as the root (highest level access) user, making it difficult to know which administrator performed any task.

It is not recommended that all administrators connect to the ESX host as the root user. Further, as a security best practice connecting to the ESX host via SSH as the root user is restricted by default.

With these restrictions and best practices, how should Service Console access be managed on ESX hosts? In truth, ESX hosts are like all other servers and best practices for security and auditing should be followed – that is, all administrators that have to login to the ESX host should do so with their own account.

For administrators, managing multiple logins for different systems can be difficult and can lead to the use of weak or common passwords. To get around this issue with VMware ESX, administrators can enable Active Directory authentication which allows them to login with their domain credentials instead of a local Linux account.

The following steps must be completed on each ESX host in the environment in order to enable AD authentication:

Configure Active Directory Authentication on ESX

1. Connect to the ESX host as the root user. Issue the following command:

   esxcfg-auth –enablead –addmoain=ActiveDirectoryDomain –addc=FQDN.of.domain.controller
   

   For example, configuring AD authentication for Kraft Kennedy’s Research domain research.kraftkennedy.com with a domain controller named nyrdc01.research.kraftkennedy.com would look like the following:

   esxcfg-auth –enablead –addomain=research.kraftkennedy.com –addc=nyrdc01.research.kraftkennedy.com
   

   Additional domain controllers can be added via additional –addc command and should be done to provide some redundancy.

2. Create Linux accounts for each administrator that needs to connect to the ESX Service Console

   Useradd username
   

   To add the “admin.liebowitz” account to the ESX host, the command would be:

   useradd admin.liebowitz
   

   As administrators leave the organization, their accounts can be removed with the following command:

   userdel username
   

3. Once authenticated, if additional access is required the administrator can issue the following command to elevate to root level access:

   su -
   

Once the above steps have been completed, administrators can login to the ESX host via SSH using their AD credentials. This allows organizations to maintain best practices by restricting root level SSH access as well as makes it easier to see which administrators have logged into a particular server.