Die Erlaubnis zur Bereitstellung neuer Websitesammlung durch Workflow

Question

Ich bin auf eine sehr merkwürdige Situation stecken.

ich einen Workflow habe, dass ich auf meiner Web-Anwendung zur Bereitstellung neuer Website. Dieser Workflow verwendet eine benutzerdefinierte Workflow-Aktivität mit der Website followoing Anweisung Bestimmung.

--- other code omited für Klarheit ----

SPSiteCollection.Add ()

Diese Aussage wirft followign Ausnahme, wenn mein applicaiton Poolkonto nicht gleich wie Central Admin applicaiton Poolkonto.

  

Zugriff verweigert. (Ausnahme von HRESULT: 0x80070005 (E_ACCESSDENIED))   beim   Microsoft.SharePoint.SPGlobal.HandleUnauthorizedAccessException (UnauthorizedAccessException   ex) bei   Microsoft.SharePoint.Library.SPRequest.CreateSite (Guid   gApplicationId, String bstrUrl, Int32   lZone, Guid gSiteId, Guid gDatabaseId,   String bstrDat

nach vielen googeln und Erkenntnissen Ich habe die applicaiton Pool Kontoberechtigung auf Null gesetzt nach unten.

Der Workflow Code läuft immer unter dem Systemkonto (die applicaiton Poolidentität). Um neue Sharepoint-Websitesammlung zu erstellen, erfordert die Anwendung Pool Zugriff auf „SharePoint_Config“ Datenbank.

Wenn meine Web-Anwendung unter dem applicaiton Pool Credential von Central Admin ausgeführt wird, hat es den Zugriff auf die Konfigurationsdatenbank. Aber wenn ich die im Rahmen einer anderen applicaiton Poolidentität leite die weniger Berechtigung hat. es wirft Ausnahme, auch wenn ich DBO Erlaubnis in der Konfigurationsdatenbank zu dem applicaiton Poolkonto geben.

Mein applicaiton Ereignisprotokoll hat folgenden Eintrag: -

  

Ereignisquelle: Windows Sharepoint   Services 3 Ereigniskategorie: Datenbank   Ereignis-ID: 3760 Datum: 2010.02.03   Zeit: 02.36.16 Benutzer: N / A   Computer: SHAREPOINT20 Beschreibung:   SQL-Datenbank ‚SharePoint_Config‘ auf   SQL Server-Instanz 'houspsr001' nicht   gefunden. Zusätzliche Fehlerinformationen   Server von SQL ist enthalten unten.

     

Datenbank kann nicht geöffnet   „SharePoint_Config“ angefordert durch die   Anmeldung. Die Anmeldung ist fehlgeschlagen. Login fehlgeschlagen   für den Benutzer 'DOMAIN \ WebAppPool'.

     

Weitere Informationen finden Sie im Hilfe- und   Support Center unter    http://go.microsoft.com/fwlink/events.asp .

Meine Frage ist, ... ist es mendatory solchen Code unter dem applicaiton Poolkonto der zentralen Admin ausführen.

Jede Abhilfe für dieses ....?

Meine Frage

Answer 1

Schließlich wird der Zugriff verweigert Problem behoben wurde. Wie ich in meiner vorherigen E-Mail bedeuten, war das Problem aufgrund unzureichender Erlaubnis meiner Anwendungspoolidentität.

• Central Admin wurde unter einer anderen Anwendungspoolidentität ausgeführt
• Web-Anwendungen werden unter einer anderen Anwendungspoolidentität ausgeführt wird.

war mein Workflow der ElevatedPrevilages zur Bereitstellung einer Websitesammlung verwendet wird, und es wird verwendet für den Zugriff aus der Datenbank verweigert zu bekommen, da es keine Erlaubnis gehabt hatte SharePoint_Config Datenbank zu ändern.

Auflösung Um dieses Problem zu beheben, ich hatte die Anwendungspoolidentität von Central Admin zu verkörpern. Hier ist die gewünschte Methode für Identitätswechsel Central Admin-Anwendungspool Benutzer.

   #region Application Pool Identity Impersonate

        protected static WindowsIdentity CreateIdentity(string User, string Domain, string Password)
        {
            // The Windows NT user token.
            IntPtr tokenHandle = new IntPtr(0);

            const int LOGON32_PROVIDER_DEFAULT = 0;
            const int LOGON32_LOGON_NETWORK = 3;

            tokenHandle = IntPtr.Zero;

            // Call LogonUser to obtain a handle to an access token.
            int returnValue = LogonUser(User, Domain, Password,LOGON32_LOGON_NETWORK, LOGON32_PROVIDER_DEFAULT,out tokenHandle);

            //Check if the logon user method succeeded
            if (returnValue <= 0)
            {
                int ret = Marshal.GetLastWin32Error();
                throw new Exception("LogonUser failed with error code: " + ret);
            }

            //System.Diagnostics.Debug.WriteLine("Created user token: " + tokenHandle);

            //The WindowsIdentity class makes a new copy of the token.
            //It also handles calling CloseHandle for the copy.
            WindowsIdentity id = new WindowsIdentity(tokenHandle);
            CloseHandle(tokenHandle);
            return id;
        }

        [DllImport("advapi32.dll", SetLastError = true)]
        public static extern int LogonUser(
            string lpszUsername,
            string lpszDomain,
            string lpszPassword,
            int dwLogonType,
            int dwLogonProvider,
            out IntPtr phToken
            );
        [DllImport("advapi32.dll", SetLastError = true)]
        public static extern int ImpersonateLoggedOnUser(
            IntPtr hToken
        );

        [DllImport("advapi32.dll", SetLastError = true)]
        static extern int RevertToSelf();

        [DllImport("kernel32.dll", SetLastError = true)]
        static extern int CloseHandle(IntPtr hObject);

        #endregion

Und dann mein Code Websitesammlung Looks zu kreieren wie: -

//Impersonate the logged in user, ApplicationUser, LoginDomain and Password are exposed as property of the class.

WindowsImpersonationContext wiContext = CreateIdentity(this.ApplicationPoolUser, this.LoginDomain, this.SystemPassword).Impersonate();



//Provision new site collection and update the property for new site collection url.

using (SPSite newSiteCollection = spSiteColl.Add(SUGGESTEDURL, TITLE, DESC, LCID, WEBTEMPLATE, PRIMARYOWNER.LoginName, PRIMARYOWNER.Name, PRIMARYOWNER.Email, SECONDARYOWNER.LoginName, SECONDARYOWNER.Name, SECONDARYOWNER.Email))

{

this.SUGGESTEDURL = newSiteCollection.Url;

}



//Reset the impersonation.

wiContext.Undo();

Answer 2

Wie Im erlaubt nicht kommentieren Sudhir Antwort, die Entsendung Im meine Bemerkung als Antwort. Ich habe im Grunde den gleichen Code, der Sudhir als Lösung vorschlägt. Der Identitätswechsel funktioniert, aber es hat eine Sicherheitslücke. Wenn Sie Ihr Passwort als Klartext gespeichert (verwaltet) string kann es wegen des Paging innerhalb des Speichers und auch gespeichert auf die Festplatte verschoben werden. Das macht es einfach für aunothrized Personen Ihre Anmeldeinformationen auszuspionieren.

Es ist daher für diesen Zweck zu verwenden Secure empfohlen. Wie dies in Verbindung mit Secure verwendet werden können, auf MSDN . Der wesentliche Unterschied zur Sudhir-Lösung ist eine andere Überlastung von Logonuser zu verwenden, nämlich

[DllImport("advapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
internal static extern bool LogonUser(String username, String domain, 
                                      IntPtr password, int logonType, 
                                      int logonProvider, ref IntPtr token);

und es wie folgt verwenden (dieser Code von MSDN):

// Marshal the SecureString to unmanaged memory.
passwordPtr = Marshal.SecureStringToGlobalAllocUnicode(pwdSecureString);

// Call LogonUser, passing the unmanaged (and decrypted) copy of
// the SecureString password.
returnValue = LogonUser(userName, domainName, passwordPtr,
                        LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, 
                        ref tokenHandle);

// Zero-out and free the unmanaged string reference.
Marshal.ZeroFreeGlobalAllocUnicode(passwordPtr);

Auf diese Weise das Passwort nur richtig verschlüsselt ist, bevor wir es verwenden, um die Benutzeranmeldung zu tun. Danach wird das Klartext-Passwort immediatelly aus dem Speicher freigegeben wird.