SSO for BDC: "You do not have the rights to perform this operation"

Question

Here's one from the vaults.

 

I've checked and rechecked all my painstakingly created-as-per-Microsoft-best-practice-guidelines Sharepoint domain accounts are configured properly, and the permissions are definitely all there.

 

However, "Manage Server Settings for Single Sign-On" reports every single one of those accounts as not having enough permissions to submit the configuration.

 

I've resorted to the drastic method of adding every permission set I can think of, to a specific new account, and running the SSO Service under that account. No joy, it still doesn't let me submit the config.

 

As a last resort I tried specifying my own delegated admin account - which is local administrator, farm administrator, site collection administrator, app pool administrator, and has full unrestricted access to the SQL Server. I logged into the Central Administration using that account. No joy.

 

So, then I tried the uber-admin account for our AD. Absolute godlike access to everything in the directory, and all SQL servers.

 

And guess what...

 

You do not have the rights to perform this operation.

 

I've been playing with Sharepoint long enough to know that the Microsoft documentation for Sharepoint couldn't be more badly written if Salvadore Dali had been translating it from Klingon while whacked out on hallucinogens, so can anyone point me in the direction of a sensible, intelligible explanation of what I must have missed?

 

 

 

Answer 1

Never mind.

 

Turns out I had to add my new AD "New MOSS Admin" group manually to a bunch of WPG groups, then reboot the server, then use that instead of the individual account when configuring SSO. All worked after that.

 

Until I did it, despite the fact the user already had the necessary access permissions, the mere omission of the user from the WPG memberships seemed to stop the SSO config in its tracks.

 

 

 

 

Answer 2

Hi,

 

Usually I find that our customers forget to configure the Single Sign On Service as a Domain Account.  Usually you find it is running as Network Service.  This might not be your issue, but even so is probably worth mentioning to anyone reading your post.  The SSO service has to run as a Domain Account.  Usually when testing this, my Domain Account that I use is the same as my App Pool ID.  Therefore it is already granted permission to the WSS_WPG group etc.  I would be interested to here more from you if you narrowed down this particular problem.

 

Also, I wrote a Whitepaper on configuring SSO in MOSS specifically with BDC if you find that useful:  www.lightningtools.com

 

 

Thanks

 

Brett

 

Answer 3

Hi,

Thanks for the info, and yes I have read your white paper!

If it wasn't for people like you I suspect that Microsoft would see a hell of a lot of people ditching Sharepoint and going for something far more cost-effective in terms of the time it takes to get the product in and working, and having people trained to a sufficient level where they can support it effectively.

It's an indictment of how bad Sharepoint is, that I HAVE TO spend all my time chasing blog entries, white papers and the like - the documentation for the product itself is shockingly poor and half the time the product just does not do what you expect it to do.

What I'm actually trying to do with BDC, is produce in Sharepoint, something roughly comparable to an ad-hoc report an ex-colleague knocked out in ColdFusion during a couple of lunch hours, a few years back.

I have no trouble presenting that data in MS Access, Excel, SQL Server, Crystal Reports or anything else  - it's a five minute job.

Even with the aid of XML generation tools, it's taken me over a fortnight trying to expose the same datasets in Sharepoint, and I'm still not there yet. I just keep hitting obstacle after obstacle.

At the moment, I've gone from not having the access rights, to having an app definition that imports without error and displays on the web page without error, but returns no records even when the list is set to "show all items". This is using a SQL account which has the correct permissions to run the stored procedures.

I have systematically tested every permutation of authentication going, and at the moment, SQL credentials is the only one that doesn't bomb out with an authentication error. I've even tried setting up SSO.

The simple fact is that Microsoft should have a process for setting BDC up, that works even when you're not doing the sodding Adventureworks demo.

Answer 4

Hi,

Thanks for the info, and yes I have read your white paper!

If it wasn't for people like you I suspect that Microsoft would see a hell of a lot of people ditching Sharepoint and going for something far more cost-effective in terms of the time it takes to get the product in and working, and having people trained to a sufficient level where they can support it effectively.

It's an indictment of how bad Sharepoint is, that I HAVE TO spend all my time chasing blog entries, white papers and the like - the documentation for the product itself is shockingly poor and half the time the product just does not do what you expect it to do.

What I'm actually trying to do with BDC, is produce in Sharepoint, something roughly comparable to an ad-hoc report an ex-colleague knocked out in ColdFusion during a couple of lunch hours, a few years back.

I have no trouble presenting that data in MS Access, Excel, SQL Server, Crystal Reports or anything else  - it's a five minute job.

Even with the aid of XML generation tools, it's taken me over a fortnight trying to expose the same datasets in Sharepoint, and I'm still not there yet. I just keep hitting obstacle after obstacle.

At the moment, I've gone from not having the access rights, to having an app definition that imports without error and displays on the web page without error, but returns no records even when the list is set to "show all items". This is using a SQL account which has the correct permissions to run the stored procedures.

I have systematically tested every permutation of authentication going, and at the moment, SQL credentials is the only one that doesn't bomb out with an authentication error. I've even tried setting up SSO.

The simple fact is that Microsoft should have a process for setting BDC up, that works even when you're not doing the sodding Adventureworks demo.

AMEN !

---

MCPD