I am on a Tridion 2011 SP1 CM server and I’m trying to start the SDL Tridion Content Manager configuration MMC snap-in.
I get the following error:
Could not read configuration item. Modification of this item is not
available on this machine. Account has no permission to access the
protected configuration section 'tridion.security'. Contact your
system administrator.
My user is of course part of the local admins.
What is going on? how to fix it?
The Content Manager uses a .NET encryption key to ensure the encryption of sensitive configuration data such as passwords. By default nothing is encrypted. The following user accounts automatically have access to this encryption key:
Any Content Manager system account (including the Content Manager user account and impersonation user accounts created during installation)
The user account of the user who originally ran the installer
The use of the configuration encryption functionality is completely transparent, so long as the following is true:
The user account that runs the SDL Tridion MMC Snap-in configuration tool is the same user account that originally ran the installer.
The user executing the various SDL Tridion Windows services is not changed from its default value.
If you want to run the Snap-in and/or Windows services as another user than specified, you must grant that new user access to the encryption key. To grant this access, log on as the user account of the user who originally ran the installer, or as another, similarly authorized user with access to the encryption key, and do the following:
Open a Windows command prompt.
Go to a directory on your machine on which a version of the .NET Framework is installed (a subdirectory of C:\Windows\Microsoft.NET\Framework\ or C:\Windows\Microsoft.NET\Framework64\).
Enter the following command:
aspnet_regiis -pa "TridionRsaKeyContainer" "<domain>\<account>" where <domain> is the domain of this user and <account> is the username of the user.
Related
What minimum user permission required on window computer to install DACPAC through DACFX API (C#). The issue i am facing is during impersonation. I am not sure what minimum window permissions required for a domain user being used to impersonate. If i am adding that user(Impersonation user) in admin group on that machine then DACPAC execute successfully, but client don't want to add that user as admin on that window machine. I am clear about SQL server permissions for DAPAC, that user is member of DB_OWNER so SQL server is not the issue but window security.
I'm working on multi tenant ASP.NET web application for digital signing.
For every tenant certificate store named "Tenant_{TenantId}" is created in store location "Local Computer" (StoreLocation.LocalMachine).
Everything works fine from windows application running under account with local administrator permissions.
When the same library is used from ASP.NET application hosted on IIS, only "Local System" identity can work with certificates.
I tried with local administrator user account and get exception Access is denied:
System.Security.Cryptography.CryptographicException: Access is denied.
Are there any restrictions on code under IIS? How to grant user/code read certificates permissions (from specific certificate locations/stores)?
Application is hosted on Windows Server 2012R2 / IIS 8.5 / ASP.NET 4.5
There are 3 options you can try.
1) Use MMC (Certificates snap-in for Local Computer).
If your store (Store1) is listed under "Certificates (Local Computer)" node, find your certificate. If the store is not listed, try to search certificate with command from context menu of "Certificates (Local Computer)" node: Find Certificates... (Find in: All certificate stores).
After you have found the certificate, you should drag&drop it to Personal store, then select All Tasks -> Manage Private Keys from its context menu, grant access to accout and finally drag&drop it to your store back.
Based on this answer
2) Use WinHttpCertCfg.exe to grant access to certificate private key
winhttpcertcfg -g -c LOCAL_MACHINE\<your-store-name> -s <cert-subject> -a <IIS-app-pool-account>
3) If you need to grant access in code take a look at solution in powershell (you can easily implement it in C#)
I am getting the below error frequently in the GUI when i try to access my custom application. and some time it preventing me to do anything in GUI. Could any one help me on this to resolve?
I am using Tridion 2011 SP1
(80040302) Impersonation by this user requires the DOMAIN\MTSUSER account to be configured as impersonation user.
Unable to get a User.
Unable to Initialize TDSE object.RESID_4537TDSE
Tridion.ContentManager.Security.AuthorizationManager.GetImpersonationUserSettings(String)
Tridion.ContentManager.Security.AuthorizationManager.LoadAccessToken(String,String)
Tridion.ContentManager.Session..ctor(String,String,UserContext)
Tridion.ContentManager.BLFacade.SystemFacade.InitializeUserContext(UserContext,String,String)
UtilitiesTDS.GetUserContext
TDSE.Initialize
TDSE.User
I think the error is quite clear. It seems that your application is running under DOMAIN\MTSUSER and you are trying to impersonate (perform action as user that is logged in to Tridion GUI). To make it work you should either run your application under one of the impersonation users, NETWORK SERVICE, for example, or any other user you can find under Impersonation Users in Tridion MMC, otherwise just add DOMAIN\MTSUSER to impersonation users in MMC
As the error states, you need to add the DOMAIN\MTSUSER account, to the impersonation user lists
You can find this option in the Tridion MMC Snap In (aka: "Sdl Tridion Content Manager Configuration") under the impersonation users list.
However you should ask yourself what tasks are you doing with this user, and is it the correct account to do it?
I am trying to debug an asp.net website on a remote IIS server.
When I debug the project, I get the error unknown user name or bad password.
After sniffing with wireshark, he is using a username that doesn't exist on my machine.
Where can you select which user it uses to do the remote debugging?
The remote debugging tool (msvsmon.exe) doesn't give you the option to select a user when you begin the debugging session in VS; it must already be configured to allow the account to debug when the session is started.
You can do this by opening msvsmon on the target system, selecting Tools -> Permissions, and adding the necessary user account(s).
From the MSDN article regarding how to configure user accounts for remote debugging across domains (which I also found useful setting up debugging from a domain system to a workgroup system):
To connect to msvsmon, you must run Visual Studio under the same user account as msvsmon or under an administrator account. (You can also configure msvsmon to accept connections from other users.)
Visual Studio accepts connections from msvsmon if msvsmon is running as a user who can be authenticated on the Visual Studio computer. (The user must have a local account on the Visual Studio computer.)
If both systems are in the same domain, this makes it a little easier:
Add a user account to the domain for this purpose (or use an existing domain account)
Add the domain user account to both systems
Configure msvsmon.exe to allow this user account to debug
Start your VS debugging session under this user account.
We are extending an existing software product, which uses Active Directory to store user credentials to a cloud solution to store user credentials.
I am wondering how we can migrate/port these AD passwords to new database instead of asking users to reset their passwords. I know we cannot retrieve the plain password but rather I would like to understand how we can port these passwords and use a specific decryption library to validate these passwords.
We can just move this passwords to new SQL database but how are we going to validate the password? Which encryption algorithm and salt we are going to use?
Thank you,
I’ve spent most of this month working with a customer who is consolidating various Active Directory forests into a single domain. We didn’t use any third party tools – just the standard Microsoft utilities, i.e. Active Directory Migration Tool (ADMT) v3 and Exchange Migration Wizard (one of the Exchange Server 2003 deployment tools) – but they seem to do the job.
As migrating several hundred users to new accounts (with new passwords) would cause a huge number of support calls, I wanted to get the ADMT password migration DLL working. This took some time, but with the help of my enterprise support colleagues (effectively a PSS call), we found a way through. This is what was required:
(For reference, both the source and target domains were in Windows Server 2003 domain and forest functional mode, running Windows Server 2003 with a mixture of service packs 1 and 2.)
Make sure that there is a trust in place between the source and target domains.
Install ADMT by running admtsetup.exe and follow the installation wizard on the computer that will be used for the migration (I used a domain controller in the source domain but ideally you would have dedicated computers for migration activities and it seems logical that this should be in the target domain).
If not already created by ADMT, create a new domain local group called domainname$$$. This group must be empty, and is required in order to migrate the sIDHistory information between source and target accounts.
On the domain controller that will be used to export the account information (usually the DC holding the PDC Emulator operations master role for the source domain), create/set a value of 1 for a DWORD registry key called TcpipClientSupport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\.
In both the source and target domains, ensure that success and failure auditing is enabled for account management.
On a computer with ADMT installed, create a password encryption key for each source domain, by shelling out to a command prompt and entering the following commands:
cd %systemroot%\ADMT
admt key /option:create /sourcedomain:<em>domainname</em> /keyfile:<em>filename</em>.pes
(the domainname can be specified in NetBIOS or DNS format.)
On the domain controller in the source domain that holds the PDC Emulator operations master role, connect to the computer with ADMT installed (e.g. via the c$ administration share) and access the %systemroot%\ADMT\PES folder.
Run pwdmig.exe to install the ADMT Password Migration DLL and follow the installation wizard. During the installation, supply the password encryption (.PES) file that was created earlier.
This is the step that’s not in the instructions – even though the password encyption file was supplied during the installation of the ADMT Password Migration DLL, it still needs to be imported manually on the PDC Emulator, by shelling out to a command prompt and entering the following commands:
cd %systemroot%\ADMT
admt key /option:import /sourcedomain:<em>domainname</em> /keyfile:<em>filename</em>.pes
On the domain controller that will be used to export the account information, create/set a value of 1 for a DWORD registry key called AllowPasswordExport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\. Note that this key constitutes a security risk and should only be enabled during the period of migration.
Restart the computer with the ADMT Password Migrator DLL installed.
Start the Password Export Server service.
Most of this is exactly as per the documentation – the main difference is the need to manually import the password encryption file. Without this, I was receiving the following message:
Error
Unable to establish a session with the password export server. The source password export server and the target server do not have the same encryption key for the source domain.
Finally, what permissions are required? I used Local System for the Password Export Server service. For everything else, I used an account which had been created in both forests with identical passwords and which was a member of the Domain Admins group. That’s a little excessive, and best practice would involve using an account with the minimum required permissions. Basically, an account is required that is:
Domain administrator in the source domain.
Local administrator on the computer on which ADMT is installed.
Delegated permissions on OUs that are targets for resource migration in the target domain, including the extended right to Migrate SID History (visible in the Security for an object using the Advanced Features view in Active Directory Users and Computers).
Further advice can be found in the ADMT v3 Migration Guide.
One option would be to implement a password filter for AD. This would allow you to capture the password as passwords get changed. I have used several products that implement a password filter to assist a ad migration, howevere I have not implemented it myself so the best I can do is suggest the Microsoft doc on it. This isn't a great option if users are not forced to change their password or cannot change this password.
https://learn.microsoft.com/en-us/windows/win32/secmgmt/password-filter-programming-considerations
Another option would be to setup a product in-between the product login and AD to capture and migrate password. Products do exist that implement a ldap interface for exactly this purpose. The product I have seen for this is Radiant logic but I believe there are other products.
https://www.radiantlogic.com/solutions/overview/how-radiantone-works/