For one particular user the signature is not being deployed,
we are using exchange and outlook 2016 and signature manager outlook edition 3.0.9.2
added user and tested with policy tester, there the signature appears.
In logs on server the test is logged and is successful
xml file is created for the user on the server
Ran exsync on local computer and checked in logs of computer and it says the signature is updated but still doesn't update.
Checked user on different computer and there is also the signature is not deployed - i.e. it is not a problem with a particular computer but this particular user
We have already been working with exclaimer for a number of years and do not have a general problem, i.e. with other users signatures have been updated
Related
I'm investigating a failure in my Windows 10 Credential Provider. It calls out to LookupAccountName in order to get the SID of the user that is attempting to log in. Its per-user configuration uses the account SID as the key.
The failure scenario is as follows:
There is a mixture of local and domain accounts on a domain joined computer.
The computer is in an offline or otherwise disconnected state and cannot contact the domain controller.
The domain user has logged in to this computer in the past and its credential is cached.
The call to LookupAccountName fails with ERROR_TRUSTED_RELATIONSHIP_FAILURE (0x6FD)
Here's where things are interesting:
I can log in with a local account and then "Run As" the domain user. Then subsequent calls to LookupAccountName (even when run in the context of the local user) succeeds in looking up the SID of the domain user. It will continue to work until the computer is rebooted.
I've tried calling LookupAccountName as well as LsaLookupNames2. Both exhibit the same behavior. (I assume LookupAccountName is built off of LsaLookupNames2).
It doesn't look like the NetUser* APIs will help me, as I believe they are intended for local accounts.
Is there a way to lookup the account SID for an offline domain credential? Without requiring them to log in first?
Why does using "Run As" cause these APIs to suddenly work?
Background
I have a Windows 7 VM with two user accounts (condor_usr1 and condor_usr2) that is used for source code compiling. The condor_usr[1|2] accounts are members of the administrators group. I have an HTCondor master VM that periodically receives jobs and assigns each job to run on one of the condor_usr[1|2] accounts. The condor service on the Win7 VM runs as the local system account, but jobs being executed actually run as the condor_usr[1|2] account.
I have a new requirement to sign the compiled executable. I've imported the certificate with private key into the Current User\Personal key store in the Windows Certificate store.
Problem
If I'm logged into the Win7 VM (e.g. via remote desktop) as one of the condor_usr accounts, then compiles running as that account will successfully sign the executable, but compiles running as the other account will fail to sign the executable. For example, if I'm logged in as condor_usr2, then compiles running under condor_usr2 will sign successfully and compiles running under condor_usr1 will fail to sign. If I log out, both accounts fail to sign.
The specific error I receive is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets(264,9): error MSB3482: An error occurred while signing: The system cannot find the file specified.
Turned on some audit logging and found the following log that occurred at the same time as a signing failure.
Goal
Sign the compiled executable successfully regardless of which account the compile is running as and without requiring a user to be logged in.
What I've Figured Out So Far
The code/project being compiled is a Visual Studio 2017 solution.
The signing method is ClickOnce manifest signing (an option in the VS2017 project).
When a compile job is started, the job logs in as condor_usr[1|2] using logon type 2 (interactive logon).
https://ss64.com/nt/syntax-logon-types.html
Things I've Tried
Unless otherwise noted, these actions had no effect and were reverted.
Adding the condor_usr accounts to the Cryptographic Operators group.
Importing the certificate w/ private key to the Local Computer\Personal key store.
Granting the Network Service account full control to the certificate/private key.
https://community.dynamics.com/nav/b/technicaltipsandtricksfordynamicsnav/posts/how-to-grant-access-to-the-certificate-s-private-key-to-the-service-account-for-microsoft-dynamics-nav-server
Using PsExec -h make.bat to obtain the account's elevated token.
https://learn.microsoft.com/en-us/sysinternals/downloads/psexec
I considered that User Account Control (UAC) may be preventing the system account and/or condor_usr account from accessing the certificate store (or private keys in the cert store), but UAC is already disabled on the Win7 VM.
I placed the original .pfx certificate file in the VS2017 solution and targeted it instead of the certificate in the key store. This had no effect, which leads me to believe that the issue is some sort of signing permission rather than (or perhaps in addition to) purely permissions around the actual certificate store.
I tried starting a job while logged in via remote desktop, and then logging out of the remote desktop session (actual logout, not disconnect) before the job got to the signing portion. Signing failed.
Make sure all the accounts involved in the process has the "Logon as service" rights by ensuring they are present in the local policy "Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Log on as a service". Note that this change becomes effective the next time the owner of the account(s) logs on.
Try running the HTCondor service directly as "condor_usr1" instead of the "Local System" account.
code:5001
message:"An internal error has occurred."
name:"Internal Error"
I get this error when I call getAccessTokenAsync in my outlook addin. In desktop version I get a another error with code:13003. With the AttachemntDemo sample I get the same errors.
You are most likely using an on-premises Exchange Server with a local Domain Account.
From the documentation:
13003
User Type not supported. The user isn't signed into Office with a valid Microsoft Account or Work or School account. This may happen if Office runs with an on-premises domain account, for example. Your code should ask the user to sign in to Office.
Also confirm that your server meets these requirements:
If the user is connected to Office 365 or Outlook.com, mail server requirements are all taken care of already. However, for users connected to on-premises installations of Exchange Server, the following requirements apply.+
The server must be Exchange 2013 or later.
Exchange Web Services (EWS) must be enabled and must be exposed to the internet. Many add-ins require EWS to function properly.
The server must have a valid authentication certificate in order for the server to issue valid identity tokens. New installations of Exchange server include a default authentication certificate. For more information, see Digital certificates and encryption in Exchange 2016 and Set-AuthConfig.
In order to access add-ins from the Office Store, the client access servers must be able to communicate with https://store.office.com.
:
Try to inspect the network traffic and see the actual request - there is more information about the error as this function is just a wrapper around the network request and does not give enough information.
I was receiving the same error and when checked the network request - discovered that I have to add one more application as a Pre-authorized application.
I'm trying to authenticate to Opends server using winldap , I installed my self signed certificate to system trusted root certificates,personal store etc(where ever applicable). ldp.exe which is a tool by microsoft works fine for ssl and tls connection .I have 2 user accounts in my PC(admin and Administrator) everything works fine for both user accounts , except my windows service.
My windows service(a library management program) couldn't verify the server certificate. but my sample code works(which is a small part of code similar to my windows service) ,
I have seen similar scenarios on this website and their suggestion (https://msdn.microsoft.com/en-us/library/aa702621.aspx).
My service displays Group name as N/A in services tab and user name as SYSTEM in processes tab of task manager and I'm not sure what to do , please some one help me to solve this issue.
Thanks in advance.
Actually Windows has 3 types of certificate stores Local User , System , Services .
Usually windows services run as a special account called System(we can make it run on a particular user account as well)
Self signed certificate is added to the local user account alone (for both admin and Administrator as mentioned). so the windows Service couldn't verify the certificate.
Solution is to add the certificate to the System store .
The program works fine
Something corrupted my user profile.
I was running a profile where I connected to a gmail via pop3 and our local exchange server. One day I killed a process via the debugger during the startup process for Outlook (I am developing an Outlook addin). Ever since that point, I cannot load Outlook with the exchange server.
I have deleted the original profile and created 2 new profiles where I separated the accounts. The pop3 one will load every time the pop3 profile is selected. The exchange one will hang on loading profile, every time the exchange profile is selected. I get the following message.
Cannot open your default e-mail folders. You must connect to Microsoft Exchange with the current profile before you can synchronize your folders with your Outlook data file (.ost).
I've tried running outlook in safe mode, addins disabled, /resetnavpane, outlook reinstalled. The exchange server is up and running just fine (I can successfully perform the Test Email Autoconfiguration).
Any ideas on what else to try?
In the end, I followed the steps from http://blog.mpecsinc.ca/2011/06/outlook-error-cannot-open-your-default.html with the addition of a exchange server reboot.
Did you just copy your OST file to a new profile? You cannot do that: OST files are bound to a particular profile.
I had the same problem and I tried:
outlook.exe /resetnavpane
... but it did not help.
I was about to delete the profiles but just then realized that one of the PST file was too big - almost 2 GB. Renaming them fixed the startup problem.