Search results matching tag 'UserProfile'

Moss: Migrating and Merging User Accounts to another domain.

Bas — Wed, 05 Aug 2009 12:15:00 GMT

Some time ago, the company that I work for, merged with another company and one of the issues that we still have, is that the users of both companies till reside in different domains.

At the moment, we have a SharePoint Intranet which is accessible for both domains, lets say domain domA and domB. Since the merge of the two companies, about 1000 users aqcuired accounts in both domains, for some reason. At the moment, some project is going on which is going to merge all the users of domA to domB, which is, in my opinion, a good case. The downside is the fact that the users with multiple accounts in the different domains MIGHT have different ownerships on documents and different permissions to some parts of the intranet.

We know that it is possible to migrate SharePoint userProfiles using the STSADM command: "STSADM -o migrateuser -oldLogin domA/sAMAccountName -newLogin domB/sAMAccountName (-ignoresidhistory), or using the object model. FYI, we are going to use the object model to migrate the users without multiple accounts, because we have about 35000 users ;)

What does this command do?
1) if the newLogin already has permissions, delete the newLogin (it still exists in the database, but is marked as deleted)
2) if the oldUser already exists and has permissions, replace the oldUser entries with newUser

So, if a user already has two accounts, the "new account (the account that will be migrated to)", will be overwritten by the old account. But what is the impact. Do all users really USE their account? and did they use it a lot, or do they just surf with it. I used the following way to investigate this:

We could use the objectmodel to find out:

Does the user have specific permissions to a site?
Does the user have specific permissions to a list?
Does the user have specific permissions to a listItem?
If not, does the user have specific permissions to any of the above via SPGroups? Keep in mind that we can ignore AD groups, because the migration of accounts itself takes care of that.

But with the amount of sites, lists and items we have, this method is way to slow. So I decided to query the database to find out wether or not a user has any permissions to a site, list or listItem. As I didn't know much of the SharePoint Content Databases, I tried to analyze a bit of it. Below is the schematic I came up with. It doesnt cover the complete database and don't shoot me if it's (totally wrong), but for me it was usable to gather the information I needed:

Due to this schema, I came up with the following queries to decide if a user has some specific permissions on a list, item or site:

1) Decide if a user is in a sharepoint group that has a roleassignment: the U.tp_Deleted = 0 decides that this entry is used for the user, if it's not 0, the entry isn't used anymore.
SELECT     *
FROM         GroupMembership AS GM INNER JOIN
                      RoleAssignment AS R ON GM.GroupId = R.PrincipalId INNER JOIN
                      UserInfo AS U ON GM.MemberId = U.tp_ID
WHERE     (U.tp_Login = '<USERLOGIN>') AND (U.tp_Deleted = 0)

2) Decde if a user has a RoleAssignment:
SELECT     *
FROM         RoleAssignment AS R INNER JOIN
                      UserInfo AS U ON R.PrincipalId = U.tp_ID
WHERE     (U.tp_Deleted = 0) AND (U.tp_Login LIKE '<USERLOGIN')

Every result has a different ScopeId, which can be assigned to the AllList, All Docs or the Webs table. So by creating a new query, there can exactly be decided to what group, item. list and site a user has access to.

Note: a role assignment is deleted if it isn't used anymore, I believe, though I didn't test this thoroughly.

UPDATE:

I just found out that I can verify if a user has any permissions somewhere on a site much, much easier:
According to http://msdn.microsoft.com/en-us/library/cc704453%28PROT.10%29.aspx, the tp_Token can be used to decide whether or not a user has permissions to a site or specific document. if it's null, there is no group that a member is user of, so he or she doesn't have any permissions. It stores information of the site groups that it is member of. The method can still be used to decide the amount of items it affects.

Quote from msdn:
----------------------------------------------------------------------------------------------------------------------------------------
The WSS User Token structure contains an array of Site Group Identifiers.

0	1	2	3	4	5	6	7	8	9	1 0	1	2	3	4	5	6	7	8	9	2 0	1	2	3	4	5	6	7	8	9	3 0	1
Magic
TokenVersion
...
NumGroupIds
GroupIds (variable)
...

Magic (4 bytes): A 4-byte, unsigned integer specifying the version of the token format. This version of the protocol MUST always use the value 0xdcd3.

TokenVersion (8 bytes): An 8-byte, signed integer specifying the site collection's security version value, which was used to compute the token. This value is not currently used and MUST be ignored.

NumGroupIds (4 bytes): A 4-byte, unsigned integer specifying the count of Site Group Identifiers within this token.

GroupIds (variable): An array of 4-byte integers for each of the site groups the corresponding user belongs to. The number of elements in the array is specified by the NumGroupIds field.
----------------------------------------------------------------------------------------------------------------------------------------

SharePoint - Retrieving login name from SPUserField in a list

Bas — Fri, 17 Jul 2009 10:41:00 GMT

For a long time I didnt know how to retrieve a login name from a SPUser field in a SharePoint List. When a user doesn't have a userProfile, he is stored in the SPUser field as <number>;#<Domain\loginName>, and when he does have a profile, his name is stored as <number>;#<name of user>. That number doesn't represent the ID in the User Profile Provider, so it wasn't possible to use that ID to retrieve the login name (or other user information).

Today, I accidentally came accros an option that allowed me to retrieve all the "standard" user information:

ID, name of user, loginname, email and some other extra information.

When making a new SPQuery, do the following:

query.ExpandUserField = true;

this option enables the access op extra user information possible. Why didn't I know this before, stupid me ;)?

SharePoint: Modifying the PeopleResults.aspx - adding custom Profile Properties

Bas — Thu, 28 May 2009 12:41:00 GMT

To modify the results of the peopleresults.aspx, a few stepts have to be taken.
In my case, a Division is added to the results.

at first, make sure that the property that you want to display, is indexed so it will be part of the People Search Scope: Go http://MOSS2007/ssp/admin/_layouts/MgrProperty.aspx and select or add the UserProfileProperty that you want to be part of the search result. Check the indexed box.

Open your own userprofile, and add some data in the field.

After this, start a new full crawl on the contentsource that has the sps:// (people search) tag in it. When its finished, you will find the Division back in your metadata properties:

Now you will be ready to modify your peopleresults.aspx:
Go to this page, and open the page in edit mode. FInd the searchresults box, and open this one in edit mode, too. Press the "XSL-editor" button in here.

in here, you can edit the xsl to add the custom userprofile properties to the results.
I am gonna add this to the office information (I know it doesnt belong there, but hey, its just an example):

find the psrch-Description, and add an xsl:with-param names divi, which selects the division userprofile property from the peoplesearch results.

<div class="psrch-Description">
                        <xsl:call-template name="DisplayOfficeProfile">
                            <xsl:with-param name="title" select="jobtitle" />
                            <xsl:with-param name="dep" select="department" />
                            <xsl:with-param name="phone" select="workphone" />
                            <xsl:with-param name="office" select="officenumber" />
                            <xsl:with-param name="divi" select="division" />
                        </xsl:call-template>
</div>

now, find the DisplayOfficeProfile section and add a xsl-param name and a check + value of that parameter to display it in the results:

<xsl:template name="DisplayOfficeProfile">
        <xsl:param name="title" />
        <xsl:param name="dep" />
        <xsl:param name="phone" />
        <xsl:param name="office" />
        <xsl:param name="divi" />
        <span class="psrch-Metadata">
            <xsl:if test='string-length($title) &gt; 0'>
                <xsl:value-of select="$title" />
                -
            </xsl:if>
            <xsl:if test='string-length($dep) &gt; 0'>
                <xsl:value-of select="$dep" />
                -
            </xsl:if>
            <xsl:if test='string-length($phone) &gt; 0'>
                <xsl:value-of select="$phone" />
                -
            </xsl:if>
            <xsl:if test='string-length($office) &gt; 0'>
                <xsl:value-of select="$office" />
                -
            </xsl:if>
            <xsl:if test='string-length($divi) &gt; 0'>
                <xsl:value-of select="$divi" />
            </xsl:if>
        </span>
        <br/>
    </xsl:template>

Save the template and press apply. Prepare for an error, but don't worry: publish the page and reload it, and your peopleresults will be updated with the custom property

LDAP Problems updating LDAP information: saving attribute values gives error: 0x8000500C - The Active Directory Datatype Cannot be Converted to/from a Native DS Datatype / LDAPConnection: The LDAP server is unavailable

Bas — Fri, 22 May 2009 15:19:00 GMT

Our customer had the wish to synchronise some Sharepoint UserProfileProperties of UserProfiles back to LDAP, so that information could be synced with SAP. The attributes that needed to be saved, where inherited from custom schemas in LDAP, which gave us some trouble. When updating attribute values in LDAP, and they inherit from the default scheme, there is really no problem. But at the moment that we tried to update an attribute that inherited from a custom schema, we saw some very weird behaviour:

private void UpdateAttribute(SearchResult sr)
        {
            DirectoryEntry de = sr.GetDirectoryEntry();
            if(de.Properties.Contains("customProperty"))
            {
                de.Properties["customProperty"][0] = "bla";
            }
            de.CommitChanges();
        }

threw a com exception: 0x8000500C - The Active Directory Datatype Cannot be Converted to/from a Native DS Datatype. It even threw the exception at the line:

if(de.Properties.Contains("customProperty"))

When trying to access a property that didn't exist or a property that inherited from the default schema, no exception was thrown. What is the case? There are 2 possibilities:

1) the schema cache can't be updated on our machine, and with the lack of a correct schema, the datatype couldn't be converted.
2) For some reason, LDAP V2 is used instead of V3, which has the problem that custom attributes can't be loaded

We didn't find a solution for this, but googled brought me an alternative solution:

the System.DirectoryServices.Protocols namespace!
I tried to make a connection to the LDAP server with the following Code:

LdapDirectoryIdentifier id = new LdapDirectoryIdentifier("LDAP://" + ConfigurationManager.AppSettings["LdapServer"], 389);

LdapConnection _LdapConnection = new LdapConnection(id, AuthType.Basic);
            _LdapConnection.SessionOptions.ProtocolVersion = 3;
            _LdapConnection.Bind();  

But this threw another error: The LDAP server is unavailable. 2 hours of trial and error brought me to the conclusion: leave the "LDAP://" when specifying the server :S

Using LdapDirectoryIdentifier id = new LdapDirectoryIdentifier(ConfigurationManager.AppSettings["LdapServer"], 389); everything worked fina, and now we have a 2-way working synchronization between a LDAP store and a SharePoint UserProfileStore!

SharePoint: Add a LDAP import connection using the BDC and a webservice to fill userprofiles with additional information

Bas — Mon, 18 May 2009 18:59:00 GMT

At the company that I work for at the moment, we have several AD's and a separate LDAP store with additional user information. For that company we are developing a new Intranet in which we want to add their accounts (account + email) and provision their userProfiles with a lot of extra information like their manager, location, division, telephone numbers etc. Adding a AD import connection and a LDAP import connection isn't possible, because the accountName isnt stored into the LDAP directory, but they unique key that is used is the email address.

In this post I will explain how to write a webservice to retrieve AD information and how to create a BDC to use this webservice to provision the UserProfiles with data.

At first, we need to create a webservice. Add a reference to System.DirectoryServices and create tweo classes:

one to create a UserProfile that is returned, and on to make a LDAP connection. In my case, they are called "UserProfile and LDAP"

[Serializable]

public class UserProfile
    {
        public string Email { get; set; } // Unique for each profile
        public string Location { get; set; }
        public string Manager { get; set; }
 
        // assumption that all LDAP values are strings and single value
        public UserProfile FillUserProfile(SearchResult sr)
        {
            Email = sr.Properties["mail"][0] as string;
            Manager = sr.Properties["manager"][0] as string;
            Location = sr.Properties["location"][0] as string;
            return this;
        }
    }
 
 

public class LDAP
    {
        /// <summary>
        /// The server domain name without any protocol specification.
        /// </summary>
        public string LdapServer { get; private set; }
        /// <summary>
        /// The user name for connecting to LDAP without any attributes
        /// </summary>
        public string LdapUsername { get; private set; }
        /// <summary>
        /// The password for connecting to LDAP
        /// </summary>
        public string LdapPassword { get; private set; }
        /// <summary>
        /// The block size for reading search results from LDAP 
        /// </summary>
        public int LdapPageSize { get; private set; }
 
        public DirectoryEntry LdapDirectoryServer { get; private set; }
        public DirectorySearcher LdapDirectorySearcher { get; private set; }
 
        public LDAP()
        {
            LdapServer = string.Format("LDAP://{0}", ConfigurationManager.AppSettings["LdapServer"]);
            LdapUsername = string.Format("uid={0}", ConfigurationManager.AppSettings["LdapUsername"]);
            LdapPassword = ConfigurationManager.AppSettings["LdapPassword"];
            LdapPageSize = Convert.ToInt32(ConfigurationManager.AppSettings["LdapPageSize"]);
            // Connect tro LDAP
            LdapDirectoryServer = new DirectoryEntry(LdapServer, LdapUsername, LdapPassword, AuthenticationTypes.ServerBind);
            LdapDirectorySearcher = new DirectorySearcher(LdapDirectoryServer);
            // Filter, should maybe be qualified further to return only the entries for people            
            LdapDirectorySearcher.PageSize = LdapPageSize;
            AddLdapDirectorySearcherProperties(LdapDirectorySearcher);
        }
 
        private static void AddLdapDirectorySearcherProperties(DirectorySearcher LdapDirectorySearcher)
        {
            LdapDirectorySearcher.PropertiesToLoad.Add("mail");
            LdapDirectorySearcher.PropertiesToLoad.Add("manager");
            LdapDirectorySearcher.PropertiesToLoad.Add("location");
        }
 
        private SearchResult GetSearchResult(string email)
        {
            LdapDirectorySearcher.Filter = "(mail=" + email + ")";
            return LdapDirectorySearcher.FindOne();
        }
 
        public UserProfile FindUser(string email)
        {
            SearchResult sr = GetSearchResult(email);
            if (sr != null)
            {
                return new UserProfile().FillUserProfile(sr);
            }
            return null;
        }
    }

now create the Webservices. Three Methods are required, but we are just going to need one working method, the one that finds a userProfile when a email address is specified:

[WebService(Namespace = "http://tempuri.org/")]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    public class BDCWebService : System.Web.Services.WebService
    {
        [WebMethod(Description = "Returns null")]
        public List<string> GetAllUserEmail()
        {
            /*
            * IdEnumerator
            */
            return null;
        }
 
        [WebMethod(Description = "Returns a single User Profile Entity by by specifying an Email address")]
        public UserProfile GetUserProfileByEmail(string email)
        {
            /*
            * Specific Finder
            */
            LDAP ldap = new LDAP();
            return ldap.FindUser(email);
 
        }
 
        [WebMethod(Description = "returns null")]
        public List<UserProfile> GetUserProfiles()
        {
            return null;
        }
    }

You an test your LDAP connection settings, username and password by starting your webservice, select the GetUserProfileByEmail method and specify your own email address. If it works, the next step can be taken: creating the BDC.

To create a BDC resource file, you need to download the SharePoint resource kit and install the ApplicationDefinitionDesigner.

Open up the ApplicationDefinitionDesigner and click on "Add LOB system -> Connect to webservice". Add the location of your webservice and click "connect"

Right click on Entities -> Add Entities -> OK -> Add WebMethod.
Drag the three webmethods on the blue canvas one by one.

Click on Entity 0 and modify its name into UserProfile
RightClick on Identifier and add an identifier. Name it "Email" as well its displayname.

Open up methods -> GetAllUserEmail -> return -> return and RightClick on it -> Add TypeDescryptor. Select as identifier: Email[UserProfile]
Open up methods -> GetUserProfileByEmail -> email -> email and set it's identifier to Email[UserProfile]
do the same for GetUserProfileByEmail -> return -> return -> email and set it's identifier to Email[UserProfile]

Open up methods -> GetUserProfiles -> return -> return -> item -> email and set it's identifier to Email[UserProfile]

add instances:
1) open up Methods -> GetAllUserEmail -> instances and Add an instance. Choose as type IdEnumerator and set its name as "GetAllUSerEmailInstance"
2) open up Methods -> GetUserProfileByEmail -> instances and add an instance. Choose specificFinder as type and name it: GetUserProfileByEmailInstance
3) open up Methods -> GetUserProfiles -> instances and add an instance. Choose finder as type and name it: GetUserProfilesInstance

Rightclick on the rootnode and choose "export". Save it to your HDD.

Now we are ready to import the BDC:
open your SharedService Provider and navigate to Import Application Definition. Select your model and import it.
Navigate to manage connections and Create a new connection:

at last you need to map your user profile properties to the BDC mapping.

When you are doing a new (incremental or full) import of your user profiles, the BDC import will start right after the AD import has been finished.

Please keep in mind to give every account enough rights to update the user profiles!
1) give the AppPoolID rights on the BDC connection
2) make sure the account has enough rights on the sharepoint_config and ssp_config db, otherwhise, the userprofiles some exceptions will be thrown.