SharePoint setup on a cross-domain one way trust environment

Its been quite a while since I have written something technical. Either too busy or did not find anything challenging enough. Well, here is one that was fairly challening considering I am not a SharePoint Administrator.

Requirement: The client had two domains - A and B. There is a one way trust between A and B such that B understands everything in A. The SharePoint instance is on B i.e., Users of A can logon to B but not vice versa.

The following solutions were possible -
1) Setup claims authentication using ADFS. Probably the best approach but not sure how the credentials in B would get validated since the trust is from A to B.
2) Imports users of A into B and keep them in sync using Microsoft ForeFront Identity Manager (FIM). This would have cost implications as FIM is not free.
3) Use AppFabric Access Control. This is relatively new and not played around with it yet.
4) Have NTLM authorization right through by using the ForeFront Identity Manager service available out of the box. This is not the best approach because of possible double hop issues later on but we decided to go ahead with this as currently authorization at the DB level was not a requirement and service accounts could be used to authentication into the DB.

Having decided on Approach 4 we decided to try this out on a VM setup. We created 2 domains A and B, created the one way trust and ensured that once user from A was added to B, he was able to logon and users of B should be able to logon to A.

Once this was done, we had to install the ForeFront Identity Manager service and then run the Profiler Service in SharePoint. This imported the users from A into B. We then added a user in A on one of the sites in B. So, things looked hunky dory until this point. But when we tried to logon to the site with the credentials of the User in A a blank page was displayed and the event logged had a security exception - Bad username/password. After a bit of thought, it was clear that the credentials were not getting validated. Reason - the service account was not able to validate the username/password from domain A! We resolved the issue by using the credentials of User in A for the service account of the Profiler service in SharePoint. Possibly not the best approach but since we have SharePoint on Domain B, I guess there is no other way out!

Comments/suggestions welcome and appreciated.

Cycling to work - a start!

This is somethng I had been contemplating for a quite sometime now but had been discouraged by well wishers as I had to commute almost 20km one way to work and with a laptop to carry it seemed impractical. Now with just about 5km to get to work I decided to give it a shot.

First thing was to get a bicycle so did a lot of googling and finally decided to visit the bicycle store and decide. Me being me it was quite likely that I would use the bicycle for a few days and then leave it to rust so decided to take it easy and bought a entry level 21 gear bicycle (Hero Octane). The reviews for this were not great but even then after sitting on it I thought it was comfortable. Bought the bicycle and it was pouring but decided to ride it back from commercial street. With the enthusiasm of a new bicycle managed to get him with a little bit of sweat. I did not stop pedalling which was quite funny as you will realise later in the post

Day 1: Left home nice and early and it seemed like hard work to get to office. I was sweating even though I wanted to take it easy. On the way back home climbing up the ramp on Gear 1 was easy but then later I saw some construction workers overtaking me with utmost ease with their old non-geared classic bikes - hmmm!!! Obviously, having paid quite a bit for 21 gears I was disappointed, got down and checked the air the convential style - by pressing the tyre with the thumb. That must be it. So, went back home, got myself a new footpump and filled in air.

Day 2: Much more easier I thought till I saw some construction workers in the evening who overtook me with ease! Went back home and tried rotating the front wheels. The disk brakes were holding them a little bit and the wheels wouldn't rotate with ease! Took an hour to finally align the disk brakes and get the wheels moving freely. Tried the back wheel and the brake pads where literally stuck to the wheels! One would have thought the guy @ the store would check all these things before delivering the bike. He takes 30 mins to check everything before delivering the bike!

Day 3: Definitely much easier this time. It was a breeze getting to the office and back. Hope to keep it going for sometime now.

Update: Its almost 6 months now and I have 2 bicycles - a Mongoose (MTB) and a RoadBike and good bikes make a difference. I have covered almost 1800kms including lot of century rides! It takes just 15 mins to reach office. That's almost 50% of what I took on day1 when I started cycling. I will probably blog on the long cycling trips separately and planning for TFN!

Pass Multivalue parameter to sub reports in SSRS

It has been quite a while since I have blogged. Obviously, cannot use that excuse that I was busy - probably not doing things which were not technical enough to be blogged.


Here I had a request from on of the teams that passing multi value parameters to the sub report is not possible and try to substantiate with this blog - http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/83d0c624-09a2-44c0-82ba-c2eb48571323. I was pretty sure this must be straight forward and hence checked this out and it may not be that simple.


The first step is to create the sub report and test it independent of the main report. Here ensure that the parameter has multi value enabled. All the other attributes of the parameter can be left to none since this will be a sub report and hence values will be sent from the main report. If you notice the parameter visibility has been set to visible. In theory, this is supposed to be internal but it keeps throwing up errors inconsistently when called from the main report if this is set to internal. Now, run this report and and ensure it works.

Now that we're done with the sub report lets work on the main report. Create the report and then add the sub report created as described above. Now, right click on the sub report within the report designer and choose sub report properties.


This should show up the dialogue shown below. Choose the parameters tab from the left menu. Add parameters and then choose the name of the parameter that you had created in the sub report. There seems to be a bug with SSRS that it does not show the name of the parameter in the drop down sometimes. Try saving the sub report and then click on the drop down. If this still does not work you can type the name of the parameter and then for the value choose the parameter that you had create in the main report
Now, the value from the parameter in the main report should get passed to the sub report. Another common mistake which should be avoided - in case you are using this multivalue parameter in the filters ensure you choose the 'IN' operate and not equal to operator.

Happy Reporting!