Installing ADAM on Vista SP1

To date, Microsoft still hasn’t released an ADAM build for Vista. We’ve since had to hack our way to get ADAM installed; however, the release of Vista SP1 presented a new set of obstacles. Basically what you’ll see is an “Entry Point Not Found” error which references the VSSAPI.DLL. In order to overcome this, you just copy the older version of the VSSAPI.DLL into the ADAM directory on your Vista machine (Thanks siudyda.com for the post).

Here are the steps to get ADAM installed on an Vista SP1 build:

1. Install ADAM on a non-Vista machine.
2. Copy the %WINDIR%\ADAM folder from your non-Vista machine to the same location on your Vista machine.
3. Create a new registry key HKLM\Software\Microsoft\Windows\CurrentVersion\ADAM_Shared. Under this key, create a new Multi-String value named “SharedFolders”.
4. Run the adaminstall.exe from the %WINDIR%\ADAM directory. Do not import any LDIF files. Note: if you experience the error mentioned above, just copy the older version of VSSAPI.DLL into your ADAM directory.
5. Complete the wizard and you should have a fully functional ADAM instance. All you need to do is import the LDIF files you want to design your schema.

Invalid DN Syntax when creating new object classes in ADAM

When recreating an ADAM directory for a project that uses custom object classes, I ran into a problem attempting to import my schema using Ldifde.exe using the following command line:

“ldifde -i -u -f export_prod_schema.ldf -s server:port -b username domain password -j . -c "cn=Configuration,dc=X" #configurationNamingContext”

Below is the error my logfile reported:

-

Entry DN: cn=xxxxx,cn=Schema,#configurationNamingContext

Add error on line 15: Invalid DN Syntax

The server side error is "The object name has bad syntax."

An error has occurred in the program

-

The problem was actually in Ldifde.exe itself. Apparently, the version of Ldifde.exe from the system32 directory does not support #macros. You have to use the version provided with the ADAM (%windir%\ADAM) installation.

Thanks to Dmitri Garilov for posting this in the news group.

Reminder: C# character escape sequences

C# defines the following character escape sequences:

• \' - single quote, needed for character literals
• \" - double quote, needed for string literals
• \\ - backslash
• \0 - Unicode character 0
• \a - Alert (character 7)
• \b - Backspace (character 8)
• \f - Form feed (character 12)
• \n - New line (character 10)
• \r - Carriage return (character 13)
• \t - Horizontal tab (character 9)
• \v - Vertical quote (character 11)
• \uxxxx - Unicode escape sequence for character with hex value xxxx
• \xn[n][n][n] - Unicode escape sequence for character with hex value nnnn (variable length version of \uxxxx)
• \Uxxxxxxxx - Unicode escape sequence for character with hex value xxxxxxxx (for generating surrogates)

Of these, \a, \f, \v, \x and \U are rarely used in my experience.

link to original post

ADFS and MySites - Enabling MySites with the Web Single Sign-On (SSO) authentication provider

There have been few online questions regarding enabling MySites interoperability with ADFS. To answer the question if it’s possible, yes.

The process is actually very simple and similar to configuring forms based auth in MOSS 2007.

So it’s probably safe to assume, by this time you’ve already completed the step-by-step guide for enabling MOSS 2007 as a claims aware application; therefore this post is a walkthrough on how to configure the Web Single Sign-On authentication to interoperate with MySites.

Assuming you already have a functional claims-aware instance of MOSS 2007 configured, when logged in as a federated user you should see that the MySites link is missing. The reason for that is MySites is tied to the Shared Service Provider which has not yet been extended to use the Web Single Sign-On (SSO) authentication provider.

In order for federated users to have access to MySites, Web Single Sign-On needs to be configured to interoperate with My Site applications.

For simplicity sake, this walkthrough assumes the MySites collection is within the same web application of the site to which they are associated. For example, https://<sharepointserver>/mysites. The recommended design from Microsoft is to have MySites as its own web application and managed independently. I’m lazy and only have a VM to prove my point, so here it is. Recommended designs for MySites should be referenced in the best practice documentation in TechNet.

Within Central Admin:

1. When first configuring your Shared Service Provider, you probably configured it under the Default zone with NTLM authentication. Extend the SSP web application to use an additional authentication provider and assign it to the Custom or Extranet) zone. (Note: Zones identify the logical separation of access restrictions to the same content.) Be sure to include the details such as port number where the new application will be hosted in and choosing the zone that this extended Web application will reside under. In my case, I extended the web application under my existing federated URL, http://extranet.treyresearch.com:<port&gt;.

2. Configure the authentication provider of this extended web application for Web Single Sign-on (SSO). Be sure to specify the Membership Provider Name as [SingleSignOnMembershipProvider2] and Role Manager Name as [SingleSignOnRoleProvider2].

3. At this point, add a provider section to the Web.config of the extended Web application. This would virtual directory for the SSP (C:\Inetpub\wwwroot\wss\VirtualDirectories\<port number of SSP>. The following snippet should be copied and pasted under the <system.web> node within the web.config.

<membership>

<providers>

<add name="SingleSignOnMembershipProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs.treyresearch.com/adfs/fs/federationserverservice.asmx" />

</providers>

</membership>

<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider">

<providers>

<remove name="AspNetSqlRoleProvider" />

<add name="SingleSignOnRoleProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fsserver/adfs/fs/federationserverservice.asmx" />

</providers>

</roleManager>

Be sure to update the <fsserver> name to reflect the web service URL of the federation server. Do an “iisreset” for the configuration to take place.

4. When you’ve completed this task, the People Picker should be able to resolve organizational claims for this web application using the SingleSignOnMembershipProvider2 membership provider.

5. Assign your federated users Personalization services permissions. Do this by browsing the SSP Admin Site: <ssp name> User Profiles and My Sites Personalization service permissions. Using the Add Users/Group link you can enter the name of your organizational claims representing your portal users. Hit the Check Names button and watch the name resolve.

Grant the following rights to the users, (1) Create personal site and (2) Use personal features.

6. The next step is to grant federated users permissions to the MySites Host. Within the SSP Admin site, navigate to SSP Admin Site: <ssp name> User Profiles and My Sites My Site settings, then within View All Site Content My Site Host Permissions.

7. Add your organizational claim that represents your federated users. You actually create a claim that defines the various types of users and set their rights here. For example, Portal Admins and Portal Users.

8. Typically you wouldn’t want to assign other users Read permissions to other users to view public areas of MySites. The default behavior grants NT AUTHORITY\authenticated users to read other users MySites. You have to grant the organizational claim representing your federated users here. Browse to your SSP Admin Site, SSP Admin Site: <ssp name> User Profiles and My Sites My Site settings. Within the Default Readers Site Group, add the organizational claim here.

9. Now test the configuration from the client computer within the account partner. Browse to https:/extranet.treyresearch.com which should authenticate you through the federated trust. The first thing you should notice is that the MySites link is now available.

10. When you click it, your site is created!

SharePoint and ILM integration

As more and more companies standardize intranet/extranet portal platforms onto SharePoint 2007 (MOSS 2007), the need to integrate identity-related needs will be asked of the ILM Administrator. It makes sense...MOSS 2007 is the front-end for business communication, web-based collaboration, information-sharing, and workflow capabilities. As many already know, ILM2 will have a WSS front-end; therefore tying it's built-in functionality into your existing intranet is a no brainer...

Just in case you hadn't seen this, Alex Tcherniakhovski has something that may provide you insight for integration (or at least give you a base to work with). At most, these should provide a good template for creating an XMA that leverages one of the out-of-box (or custom) web services from MOSS 2007.

Connecting ILM 2007 with SharePoint Service Lists

Below is a brief rundown of the Web services that a MOSS 2007 makes available out of the box:

• http://server:5966/_vti_adm/Admin.asmx - Administrative methods such as creating and deleting sites
• http://server/_vti_bin/Alerts.asmx - Methods for working with alerts
• http://server/_vti_bin/DspSts.asmx - Methods for retrieving schemas and data
• http://server/_vti_bin/DWS.asmx - Methods for working with Document Workspaces
• http://server/_vti_bin/Forms.asmx - Methods for working with user interface forms
• http://server/_vti_bin/Imaging.asmx - Methods for working with picture libraries
• http://server/_vti_bin/Lists.asmx - Methods for working with lists
• http://server/_vti_bin/Meetings.asmx - Methods for working with Meeting Workspaces
• http://server/_vti_bin/Permissions.asmx - Methods for working with SharePoint Services security
• http://server/_vti_bin/SiteData.asmx - Methods used by Windows SharePoint Portal Server
• http://server/_vti_bin/Sites.asmx - Contains a single method to retrieve site templates
• http://server/_vti_bin/UserGroup.asmx - Methods for working with users and groups
• http://server/_vti_bin/versions.asmx - Methods for working with file versions
• http://server/_vti_bin/Views.asmx - Methods for working with views of lists
• http://server/_vti_bin/WebPartPages.asmx - Methods for working with Web Parts
• http://server/_vti_bin/Webs.asmx - Methods for working with sites and subsites

Password Sync using the SAP ERP MA

Does the Microsoft ERP MA from Microsoft support password synchronization? My immediate answer is yes, however there are a few things you need to consider. Most of all, the reason for this is that the documentation is pretty cryptic in itself and unless you are on a SAP project or have a development environment available, being able to test this yourself can be challenging.

According to the ERP MA README.htm, only "administrative password reset" operations are supported. Now, referencing the PCNS technical material, I found the definition as follows:

"An automated password synchronization solution in ILM allows users to change their passwords in all connected data sources that are configured for automated password synchronization. Typically, users can press CTRL+ALT+DEL on the keyboards to initiate a password change.

This is a password change operation, not a password set or reset operation. For a password change operation, a user must know the previous password when attempting to change passwords. For a password set or reset operation to occur, a user does not have to know the previous password to set or reset the password to a different value. The automated password synchronization solution is a password change operation because users know the previous password."

Well, this is a question that comes up a lot and this post should provide you with an idea of how to sync passwords between SAP and AD. An article I'd like to credit is the thread between Markus and Peter regarding this topic. Here Peter talks on a method similar to what I've run into.

My experience is initially, it seemed like password synchronization would work out-of-box; however an issue I ran into was that whenever a system administrator assigns a new password to users, the new password is marked as "initial." Users have to change their initial passwords at first logon. Apparently, I though you could simply just turn this option off. According to the SAP Knowledge Warehouse, you have to modify the SAP User Management Engine (UME) properties using their Config Tool. (Your SAP Admin should be familiar with this and provide feedback.) The setting you modify is the ume.logon.security_policy.password_change_required to reflect, False (not to require a password change at first logon). Well, the final solution resulted in creating a new SAP BAPI, similar to what Peter did. (Thanks Franciso Corona for confirming!) From there, as long as the password policies aren't conflicting each other, you should be good.

Other obstacles I’ve run into that have prevented me from syncing passwords are the policy limitations applied in SAP. Depending on version, the following rules may apply:

1. Passwords must be 3-8 characters long.
2. Passwords cannot begin with 3 identical letters
3. Passwords cannot begin with a “?” or a “!” or a space.
4. Passwords cannot be identical as the previous passwords used
5. Passwords cannot be “SAP” or “Pass”
6. Passwords cannot begin with the first letters of your name.

Most typically, by leverage AD as an authentication provider, this would get you the closest to achieving true single sign-on; however we understand that isn’t the case in many scenarios.

If you are running SAP on Windows, SAP GUI can be configured to authenticate against AD (including Kerberos SSO without any 3^rd party vendors). This does not apply to UNIX; here you would need something like Centrify.

If you are just using SAP Enterprise Portal and IViews, SAP Portal can be configured to authenticate against AD or ADAM.