0
Completed

Installer does not create permission for user in database

Peter Wass 7 years ago • updated by anonymous 3 years ago 5

The Service Account user is not created in the Database and therefore the service cannot start. I would expect that the user would be created if the database is being created.

Affected Versions:
Fixed by Version:

Moved to v4.1 for consideration as this could be problematic and all of the ramifications should be thought out.

This may be possible with CREATE LOGIN and CREATE USER (see http://msdn.microsoft.com/en-us/library/ms173463.aspx).

Although we should discuss whether this is actually desirable.

Should be examined in v4.1.1 for LITE; currently a new database will need to be given permissions manually.

Good afternoon,

This week we’re looking at ways to make the Identity Broker installation process easier, specifically with regards to LITE. I know this is not a new request as both of you (particularly you Matt) have been asking for this for some time, but a combination of tighter pre-requisites for LITE (Server 2008 R2+ etc) and me finally reading the finer details of why Server 2012 application certification (the only one we care about now) is more lax with regards to installers, we’re finally in a position to do something about it. Currently we’re working off the following issues (some are duplicates of yours Matt which I just haven’t tracked down, will do so before we close them)

For now I have one specific question about IDB-490 in the context of wanting this to work “out of the box” for as many (think 80-90% of installs) as possible, with manual install taking care of the rest.

With regards to the creation of the database, which account do you think should be doing this?
• Installer context (logged in user or the one you elevated to in order to execute the installer)
• Specified account (Either IDB service account or SQL Auth credentials)

Definitely believe it should be option 1 as you have indicated below. This is consistent with the FIM model, which sets an expectation we can follow.

Right now it’s a bit of a hybrid, with the first being used if “Current Auth” is selected and the latter if SQL Auth is selected. My initial thought of what it should be is:
• Installer context creates the database
• Once the database is created, installer context gives necessary permissions to the account IDB will use (IDB service in most cases but sometimes SQL Auth) for that specific database

Agreed (SQL auth in SQL is supposed to be only there for legacy support - surprised it is still supported).

But it would be nice to get some confirmation from either of you on that. This is all subject to it being technically feasible in the installer framework we’re using, of course.

As a more general thing, please look through the other issues and let me know if you know of additional information that might be helpful to us or if there’s additional prerequisites that I haven’t thought to cater for.

Regards,

Patrick Johannessen

The installer now creates the login (for the instance) and the user (for the database) if they are not already there. Permission is granted to the Identity Broker database (db_owner).