Access Denied When Manually Publishing A CRL - pki

I have recently built a two-tier PKI infrastructure. This infrastructure consists of an offline root CA named: xxxx-ROOTCA and an online enterprise CA named: xsxx-SUBCA1.
The server xxxx-SUBCA1 also has an internal web site configured on it to which I want to publish the CRLs.
I have issued a handful of certificates during testing that I would now like to revoke. When I go to manually publish the CRL, I get the following error message: Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS-DENIED)
In trying to find a solution to this issue, I have come across several resources that state the computer account of the CA must be given additional rights on share where the CRL list is to be published. I've gone into the share (located at D:\pki on xxxx-SUBCA1) and given the xxxx-SUBCA1$ computer account full control share permissions and full control NTFS permissions. I have also made sure the computer account has the same level of share and NTFS permissions for c:\windows\system32\certsrv\certenroll.
If anyone can help me figure out what I have done wrong here, it would be greatly appreciated.
Best regards,
NTD_1313

You need to give the Cert Publisher group write permission on your share on the web server.
Also, note that (unless this is a lab environment) your web server shouldn't be on the same box as the CA.

Related

Microsoft Graph API Problems iOS : Unable to Complete Request Validation Error

I have registered my application here.
I have given all permissions to my App in that panel as well.
I specifically need Groups.ReadWrite.All which requires an admin ? requirement I am not sure what this even means.
https://apps.dev.microsoft.com/#/application/
Okay App is registered and redirect url has been copied.
Now I take that redirect url copy it and paste it into the admin panel for apps. At this link at App Registrations
https://portal.azure.com/
I am not sure why I have to register in two different panels, one which gives me a redirect url for my native app and the other that leaves it blank.
Great So then I setup my iOS app to make a graph request. This scope
https://graph.microsoft.com/Calendars.ReadWrite
I need to readwrite groups so I add this permission
https://graph.microsoft.com/Group.ReadWrite.All
It fails to authenticate.
I have checked that I have added the permissions to my app, and I have at this app registration panel https://apps.dev.microsoft.com/#/application/
Then I try to add the same permissions in the
https://portal.azure.com/
it gives me
Unable to Complete Request Validation Error, then doesn't do anything.
I tried to add a non admin permission same error.
So what is going on here ... ?
So even though they told me use the Graph API from now on moving forward in the docs I tried to go back to their office 365 SDK for iOS, it also has problems as I cannot get the pods to work as per instructions.
I am 100% sure after this issue is resolved I will need permissions
Note: I work at as a consultant for a bank so if someone can tell me what the azure administrator at the bank has to do to get my permissions escalated to admin status that would be great....
Thanks
Those are 2 different registrations,
Per this documentation (https://graph.microsoft.io/en-us/docs/authorization/auth_overview), for personal accounts like live.com or outlook.com, use the Azure AD v2.0, and for the enterprise, use the Azure AD.
So, for your case, I believe you need the latter, the azure AD.
For this to happen, as you said, go https://portal.azure.com/ and add the app registration.
In order to do so, you would need to
select "Azure Active Directory" and go "App registrations".
Once you create an app, you would need to select "native" for the iOS, and then under app access, under "required permissions" add "Microsoft Graph" followed by selected permissions you would like.
To answer the note, you would need permissions to create an app at the portal, otherwise, you would need to ask for that permission or have the admin create an app for you.
Some samples are available at https://github.com/microsoftgraph/ios-objectivec-connect-sample and https://github.com/microsoftgraph/ios-swift-connect-sample for iOS samples.
Hope this helps!

Sign In Sorry, but we’re having trouble signing you in. We received a bad request

I am using azure AD authentication to authenticate a user in my MVC
application.And I published my application on azure and it is
working fine.
But, when I run my application locally then it Microsoft's login
page comes up and when I enter credentials and click on SignIn
button then it is giving "Sorry, but we’re having trouble signing
you in.We received a bad request."
But the same application is on azure and if I access it from there then it allow me to login.
To create this apllication I follwed link to add azure AD authentication
If you notice the error message, it clearly indicates that you have not configured https://localhost:44320 as one of the reply addresses.
Please go back to application configuration screen in your Azure AD and add https://localhost:44320 as additional reply address. That should take care of this problem.
Add the below to your Web.config. It must be the same port which you have added at the time of Application registration.
<add key="RedirectUri" value="https://localhost:44320/" />
I hit this, it has cost me a lot of time.
I would check firstly that you have the ability in Azure to access third party applications.
In Azure > Users & Groups > User Settings:
You see the first item (Users can allow apps to access their data) - without this checked I believe it wont work.
As you are running your application locally it is not published to Azure, this means that although it may be within the realms of your organisations network, Azure still views it as a third party application.
Be wary setting this to 'Yes'. I understand that there are ways to then create applications that allow you to behave as an Azure super user....
In case anyone else comes across this, here is what happened to me. I had been switching back and forth between environments within Visual Studio (Project >> Properties >> Debug >> Environment Variables). Well, the last time I switched it, I wrote "Develop" instead of "Development" to switch back. This caused .NET Core to grab the wrong appsettings which connected to the wrong AD which did not have my localhost setup on it. It took me an hour to catch what I had done wrong.
This may not be exactly what has happened to you, but do check to make sure you are picking up the Azure AD settings you are expecting if they are in your appsettings. It could be a good point to start at.

Apple MDM OTA - Identity Certificate with SCEP vs PKCS12 embedded within the profile

I'm debating and need to know the implications of not using the SCEP protocol for the mdm enrolment, more precisely the Identity certificate (the certificate credential used for authentication). I'm talking about the certificate in the Identity section on IPCU, as shown in the image below, with the red arrow.
I wont be pushing down profiles with sensitive informations (like vpn, email, etc configurations and/or passwords).
My use case will be 99%:
Block/unblock apps by rating
Lock/unlock device
Block/unlock web domains
From reading around StackOverflow (here and here) the following scenarios can happen.
If someone get access to the certificate he will be able to impersonate an enrolled device, but he will only be able to receive commands/profiles and not initiate commands/profiles. Am I right?
A man in the middle attack can get access to the certificate
The advantage of using the PKCS12 embedded within the profile is that it is faster to implement and no external dependencies (SCEP server) but I'm not so sure about the disadvantages. So my questions and doubts is:
What can a malicious person do with the private key from the Identity certificate?
Can it be a security breach going with the PKCS12 embedded approach?
This is mostly a question of SCEP vs PKCS12 embedded within the profile, pros and cons.
Here my thought on that:
1) If you are building a prototype or a small not critical service then go with PKCS12.
2) If you are building a serious product (production and touching devices of people with sensitive info) then go with SCEP (you can get a free SCEP servers. It's not that complex).
Frankly, If I was on the dark side (trying to hack it) I don't think that I would attack PKCS12 vs SCEP (it's not the weakest link)
However, let say, I say I decided to try to hack it
I would try to do man in the middle. I will try to capture communicarion, save PKCS12 and password for it
I will use it to authenticate to MDM server.
You are right, I can't trigger any commands, but I can start probing your code to find where you skipped some security checks. Maybe you don't check that a certificate matches a device UUID and so on.
Hopefully, I will find enough security holes to do something (let say trigger actions for other users). Maybe I will send them Wipe command or may be I will try to install a root CA + HTTP proxy configuration to see all their traffic.
Anyhow. I don't think that it's that weakest link and it requires a lot of additional step to get to some interesting stuff. However, if you get there, you can do A LOT.
As a result for a serious product, it will make sense to invest several additional weeks in SCEP.

Excel 2010 interop issues

Right, this is driving me insane. This works fine locally with Excel 2013, but when the website is published to a remote server with Excel 2010 it fails. From what I can see the DCOM configuration is the same locally as remote.
After fighting with Excel 2010 and DCOM permissions for over an hour now the best I have got is this exception: System.Runtime.InteropServices.COMException (0x80070BBC): Office has detected a problem with this file. To help protect your computer this file cannot be opened.
This is the result of a web application trying to open a *.xls file from a location it has just uploaded to. The application pool is running under ApplicationPoolIdentity and I have set the permissions for this specific app pool under mmc -32 on Launch and Activation Permissions so there's no problem running Excel. What I think I'm facing here is protected mode issues as the file is definitely not corrupt.
I've gone into Excel and Trust Centre settings and have added the location where the *.xls file is uploaded to (and subsequently opened) as a trusted location. If I open the file on the hosting server (under my domain account) I don't get the protected view block on the file - however, the Identity on the DCOM configuration is set to the launching user. So, what does this mean from the following (or something I haven't listed):
I need to add this location as trusted at a group policy level because the account launching the actual application doesn't have this configuration in its profile?
I need to create an actual account on the server and use this account as the Identity for running the application?
... ?
Just to clarify I've already been down the DCOM Security config route and RIDICULOUS issues with C:\Windows\System32\config\systemprofile\Desktop and C:\Windows\SysWOW64\config\systemprofile\Desktop. The configuration is:
.NET 4.5 (classic pipeline) app pool running under ApplicationPoolIdentity
DCOM Config > Security > Launch and Activation Permissions all set for this specific identity (Access Permissions and Configuration Permissions all set to Use Default)
File is uploaded correctly and appears in destination, opening on the server itself (under my domain account) respects the Trusted Location and doesn't give protected mode warning
Process to parse fails with the above exception.
Here is a screenshot of the Interop assembly I'm using if this is pertinent.
Ok... for anyone stumbling on this issue I have bitten the bullet and had to do the following:
Create a local account (AutomatedOffice in my instance) and set DCOM config to run Excel under this account
Log in as above account and change Excel settings to add folder in application root to trusted location and disable protected mode messages
Allow "Network Service" to invoke DCOM processes locally (through server DCOM config and not CLSID config)
Add NTFS permissions for this account on C:\Windows[System32|SYSWOW64]\config\systemprofile\Desktop paths
What was weird, after creating the account I was getting the following exception Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. which was resolved by adding HOST\Users and HOST\NetworkServices group to DCOM security (local only!!!) settings.
You need to add in trust center, security locations the folder where your website is published, for examplo if your website reads a file from c:\temporal\ you must put on excel, security locations that folder name

Do auto-enrolled certificates follow you around?

If you auto-enroll an account for an X.509 certificate in a Windows PKI environment, do you get the same certificate (and, by extension, private key) on every computer in the domain that you log into, or does a different certificate get issued for each computer you log into?
I would expect there would be a single certificate that would appear in the CurrentUser certificate store on each computer you logged into. But this is a matter of dispute and I don't have an environment where I can test it.
Are there any subtleties of configuring the certificate template that affect this? Does not using roaming profiles affect this?
If it matters, I am most interested in how this works for service accounts, but I expect it would be the same as for interactive user accounts.
Our PKI is currently Server 2003. It should be migrated to Server 2008 within a year.
Win2K3 does support something called "credential roaming". I haven't investigated it myself, but did come across a document explaining it: http://technet.microsoft.com/en-us/library/cc700848.aspx

Resources