We wish to automate the process of applying a S/MIME certificate to Outlook so that it can be used for Signing and Encrypting of email. We want to be able to programmatically set security setting preferences for: the signing & encryption certificate and their corresponding algorithms.
Can we make use of Outlook MAPI or the Graph API for this purpose? Which call / field (group) should we use? Our preference is to use a C/C++ API.
For anyone trying to do the same, the following script is great (or a great place to start) for setting an S/MIME certificate to Outlook including the required settings.
https://github.com/glueckkanja-pki/PKI-Configuration-Tools/blob/master/ActivateSignatures.ps1
The scripts edits the registry entry which contains the Outlook security settings. You can run the Powershell script using 'system("start [...]")' or 'CreateProcess' for example.
To answer the subquestions: I have not found a way to do this through either Outlook MAPI nor Graph API. The registry entry is: HKEY_CURRENT_USER\Software\Microsoft\Office\"version, 16.0 for me"\Outlook\Profiles\"Profile Name"\c02ebc5353d9cd11975200aa004ae40e
Related
Has anyone figured out how to verify a Salesforce domain with Apple Pay?
Basically, Salesforce does provide a way to verify a domain by going to Setup - Domains and clicking Verify. That prompts you to upload the verification file but Salesforce seems to place it under
https://your.domain/.well-known/apple-developer-domain-association.txt
whereas Apple is looking for it at
your.domain/.well-known/apple-developer-merchantid-domain-association.txt
(note the extra merchantid- in the file name).
The main issue is that Salesforce's multi tenant platform doesn't allow for direct access to the file that's placed in .well-known directory and there doesn't seem to be any way to control the file name. Is there any alternative way to verify domain ownership in this case?
I have access to a SQL Server DB system that only allowed "Windows Authentication" - that is, use your windows login credential to access the data. (Not using a username-password). It also controls database permissions.
I want to build a REST API for users not familiar with SQL to get data from that server. The problem is, I need to take user's credential to execute the command, not the machine that hosts the REST API. How could I design the system that allow user to pass their login and let the API send query to the server using that specific login?
I found a reference from Microsoft, not sure if it's relevant.
https://learn.microsoft.com/en-us/sql/relational-databases/security/choose-an-authentication-mode?view=sql-server-2017
What you are after is Kerberos delegation, sometimes also known as "double hop". It is not something you have to explicitly implement in your code, as long as you stick with the Microsoft stack; rather, it is a matter of configuration.
This post describes the setup required for the feature to work in sufficient details. You can also find some basic requirements in this help article. For anything beyond that, just google it.
We have an application that uses AD LDS (ADAM) which contains a extended user class ( custom attributes, specific to our application).
One of our clients wants our users linked to their domain users (AD).
When they create a user in their system, a user on our side has to be created. When they delete a user on their system, the corresponding user should be deleted on our side. The same with basic properties (name, email, ...).
The application specific attributes will be modified by our tool.
What is the best or most reliable way to keep those users in sync? The client does not allow us to modify their schema.
I was thinking myself to create a webservice to add/ delete / modify a user on our side which kan be called from within their system. But Maybe there are better solutions.
Thanks.
Personaly I will use ADAMSync for that. You can a kind of 'how do I' in Synchronize ADAM (or LDS) with Active Directory Domain Services.
ADAMSync.exe and ADShemaAnalyser.exe are part of the binary installed with ADAM.
In the case you are affectively using ADAM, be careful to install the ADAM SP1.
You can use the free Identity Integration Feature Pack from MS to sync selected attributes between AD and AD-LDS. You can download it here http://www.microsoft.com/download/en/details.aspx?id=11149
I'm not sure if it supports server 2008. It may be included in server 2008 as a role now.
i'm developing a .net winforms desktop application intended to be run at several bank's branches as a backup application whenever the main one (a web application) is unavailable due to connection issues with the bank's central node. The branchs themselves don't count with any enterprise services besides a SQL-Server database. For that reason, the application should be able to connect directly to the SQL-Server. My problem arises when I have to provide the application with a password to connect to the database:
1) Storing the password in clear text in a app.config file or similar is not an option (the customer requires the password to be encrypted)
2) Storing the password encrypted in a configuration file leads to the need of having an encryption key locally available. The encryption key could be just hardcoded in the application's code, but it would be easily readable by using a .net-decompiler or similar.
3) Using a custom algorithm to encrypt/decrypt wouldn't work either due to the same reasons as 2).
4) Integrated security is not supported by the bank
Additionally, the customers requires that they should be able to change the password in one location (within a branch) without the need to go from one computer to another updating config files (that rules out the possibility of using the machine's key to encrypt the password in individual machine's config files like asp.net does)
Would you provide any other approach or suggestion to deal with this problem?
I would appreciate any help.
Thanks in advance,
Bernabé
I don't think that encyrpting the password by any means is going to solve your problem. If the user has to send the password to server, and the password is located on the box, then by definition the user running the application must have access to the password and be able to decrypt it. Otherwise, you wouldn't be able to authenticate them. This means that there will always be a way for the user to get at the password, regardless of where you store it.
I can think of 2 ways that could possibly work, but I'm afraid they're not exactly what you're looking for.
Remove the requirement of having the
user send the password to the server
by using some sort of local proxy
(for example using a WCF windows
service) to take your winform
requests and then send them on your
behalf to the DB server. If you
install the service using an account
different from the user's account,
then you can secure the password by
any of the means mentioned in the other
answers. They key here is to make
sure the application user does not
have access to the resources that
the service account needs to decrypt
the password.
Don't store the password in the web config. Assign each user a different user account and password at the database level and have them type it in when they log in.
You could use the protected configuration built into .Net. See Encrypting Configuration Information Using Protected Configuration in the MSDN docs. One of it's raison d'etres was to encrypt data such as connection strings in config files.
You could
To use DPAPI to store a encryption/decryption key securely: How To: Use DPAPI to Encrypt and Decrypt Data
To install a SQL Server Compact Edition (or another small database) into your workstations and to synchronize data when your web application comes online again.
To ask for help inside that institution, as other people could have solved that problem and could to help you.
Definitely agree with the above regarding DPAPI. Microsoft's Enterprise Library makes this an absolute breeze too, so I would consider looking there first.
I have a project requirement where I need to authenticate against ActiveDirectory in a remote/disconnected WPF application.
There is probably several ways to attempt to do this, but what would be the best approach using ActiveDirectory's MembershipProvider?
I need to:
Authenticate that the user exists.
obtain the AD user's groups and roles.
This needs to happen from a remote location, outside of the network Active Directory resides on.
From within a WinForms or WPF application you can now take advantage of "Client Application Services" (thanks MS for a very generic name, searching for help is now very painful!).
This allows you to connect to a WCF service that can validate the logins. The link above has a walkthrough that shows how easy it is to get it all working, once you have a working app you can modify your config to point to a different MembershipProvider and/or RoleProvider.
It's worth noting that the out-of-the-box solution includes a MembershipProvider named ActiveDirectoryMembershipProvider, but there's no RoleProvider for Active Directory.
If you do require the ability to get Roles (or Groups) and you are working with .NET 4.0 then you can take advantage of the new Active Directory API added that makes everything much easier, namely System.DirectoryServices.AccountManagement. For the most basic of Membership and Role services you'll want to have the following to create your own basic MembershipProvider and RoleProvider:
MembershipProvider.ValidateUser() - should use PrincipalContext.ValidateCredentials()
RoleProvider.GetAllRoles() - use a new GroupPrincipal() as a source to a new PrincipalSearcher()
RoleProvider.IsUserInrole() - use UserPrincipal.FindByIdentity() method to get a user, use GroupPrincipal.FindByIdentity() to get the group, then use the IsMemberOf() method on the user to see if they're a member of the group.
You can implement as little or as much of the API as needed, you should find everything you need in the new AccountManagement namespace to do this.