Hi, since I am working with Windows PKI (10+ years) I noticed that a Windows CA is running into a situation where the CRL has expired and the CA service will never renew it until you force it to do.
That happens if the CA is down for maintenance or restore right at the time the renew of the CRL would be triggered. So that is bad but only things we cannot change keep us awake at night and so here is the solution for that problem.
I recommend to issue the CRL e.g. for issuing CAs with a validity between 10 and 14 days, no longer and definitely not much shorter until you are 110 percent sure about you recovery process and you have tested it in real before. I had once a client they promised to have any machine recovered within 4 hours. We had a bad hard drive or controller and one came to the other. We asked for a recovery what happened 4 days later. Okay so if your CRL is to short you get a lot of pressure at this point.
As in any good PKI project you can ask certutil.exe for help.
A certutil.exe -CRL command triggers the CA to issue a new CRL. Depending on your configuration that file goes into LDAP and/or on the file system. With certutil.exe -getcrl myCAcrlfile.crl you get it from the CA as well e.g. in case you want copy it to multiple web servers.
That can do a scheduled tasks e.g. executed once a day or night
So that gives us some advantages:
1) we see every day a new CRL (like a heartbeat ;-))
2) the new CRL has always the max validity period
3) is contains the latest revoked certificates, if any
4) even the CA was down for maintenance at the point of CRL renewal, the schedule task will take care of the CRL renewal
If you make use of certificate revocation a lot that is also the way to trigger the CA to issue new CRLs more often. Just run it more often.
Until next time,
Lutz
Friday, April 1, 2016
Thursday, March 31, 2016
certutil.exe shortcut
Hi,
currently I am working with great people on a PKI project. So it came how it has to come, we use certutil.exe for various purposes and we came across a nice shortcut I want share.
So every time you use certutil.exe to query a CA server from remote you have to specify the config information. (Actually the -ping allows you just to specify the CA hostname, no -config necessary)
e.g.
C:\system>certutil.exe
Entry 0:
Name: `AAA-trii-CAI01'
Organizational Unit: `'
Organization: `tribaldi'
Locality: `'
State: `'
Country/region: `'
Config: `cai01.tribaldi.net\AAA-trii-CAI01'
Exchange Certificate: `'
Signature Certificate: `'
Description: `'
Server: `cai01.tribaldi.net'
Authority: `AAA-trii-CAI01'
Sanitized Name: `AAA-trii-CAI01'
Short Name: `AAA-trii-CAI01'
Sanitized Short Name: `AAA-trii-CAI01'
Flags: `1'
Web Enrollment Servers: `'
CertUtil: -dump command completed successfully.
So then you copy the config value and use it like:
C:\system>certutil -catemplates -config "cai01.tribaldi.net\AAA-trii-CAI01"
3b_clmAgent: 3b_clmAgent -- Auto-Enroll: Access is denied.
3B_enrollment_agent: 3B_enrollment_agent -- Auto-Enroll: Access is denied.
3BUser_onbehalf: 3BUser_onbehalf -- Auto-Enroll: Access is denied.
WebServerORG: Web Server ORG -- Auto-Enroll: Access is denied.
3bcomputer: 3bcomputer -- Auto-Enroll: Access is denied.
ISE_BYOD: ISE_BYOD -- Auto-Enroll: Access is denied.
BYOD: BYOD -- Auto-Enroll: Access is denied.
WebServer: Web Server -- Auto-Enroll: Access is denied.
IPSECIntermediateOffline: IPSec (Offline request) -- Auto-Enroll: Access is denied.
CEPEncryption: CEP Encryption -- Auto-Enroll: Access is denied.
EnrollmentAgentOffline: Exchange Enrollment Agent (Offline request) -- Auto-Enroll: Access is denied.
CertUtil: -CATemplates command completed successfully.
So while that is cool for scripting purpose, e.g. for documentation, the shortcut is much simpler. Instead of the value behind the config parameter you can just type a dash (minus sign), and that will open a dialog showing you all CA registered in AD. See here
P.S. these examples are created from Windows 2012 R2 machines.
currently I am working with great people on a PKI project. So it came how it has to come, we use certutil.exe for various purposes and we came across a nice shortcut I want share.
So every time you use certutil.exe to query a CA server from remote you have to specify the config information. (Actually the -ping allows you just to specify the CA hostname, no -config necessary)
e.g.
C:\system>certutil.exe
Entry 0:
Name: `AAA-trii-CAI01'
Organizational Unit: `'
Organization: `tribaldi'
Locality: `'
State: `'
Country/region: `'
Config: `cai01.tribaldi.net\AAA-trii-CAI01'
Exchange Certificate: `'
Signature Certificate: `'
Description: `'
Server: `cai01.tribaldi.net'
Authority: `AAA-trii-CAI01'
Sanitized Name: `AAA-trii-CAI01'
Short Name: `AAA-trii-CAI01'
Sanitized Short Name: `AAA-trii-CAI01'
Flags: `1'
Web Enrollment Servers: `'
CertUtil: -dump command completed successfully.
So then you copy the config value and use it like:
C:\system>certutil -catemplates -config "cai01.tribaldi.net\AAA-trii-CAI01"
3b_clmAgent: 3b_clmAgent -- Auto-Enroll: Access is denied.
3B_enrollment_agent: 3B_enrollment_agent -- Auto-Enroll: Access is denied.
3BUser_onbehalf: 3BUser_onbehalf -- Auto-Enroll: Access is denied.
WebServerORG: Web Server ORG -- Auto-Enroll: Access is denied.
3bcomputer: 3bcomputer -- Auto-Enroll: Access is denied.
ISE_BYOD: ISE_BYOD -- Auto-Enroll: Access is denied.
BYOD: BYOD -- Auto-Enroll: Access is denied.
WebServer: Web Server -- Auto-Enroll: Access is denied.
IPSECIntermediateOffline: IPSec (Offline request) -- Auto-Enroll: Access is denied.
CEPEncryption: CEP Encryption -- Auto-Enroll: Access is denied.
EnrollmentAgentOffline: Exchange Enrollment Agent (Offline request) -- Auto-Enroll: Access is denied.
CertUtil: -CATemplates command completed successfully.
So while that is cool for scripting purpose, e.g. for documentation, the shortcut is much simpler. Instead of the value behind the config parameter you can just type a dash (minus sign), and that will open a dialog showing you all CA registered in AD. See here
And that will give you exact the same result as in the command before.
Until next time,
Lutz
P.S. these examples are created from Windows 2012 R2 machines.
Tuesday, September 29, 2015
execute command prompt under Local System or Network Service account
Running tasks under a different user context as you are just logged in is a quiet common tasks as a Windows server administrator. I like especially the local system account to sync files to other servers and I just assign permissions on the destination server under the source server name. That eliminates the need of having an service account with password or to have managed service accounts.
To run a script under the Local System account I used to create a scheduled task to execute the script. It is working but troubleshooting is a little tough because you do not see the console output.
Recently I came across this article http://blogs.msdn.com/b/beanexpert/archive/2015/06/11/azure-ad-application-proxy-connector-connectivity-issues-with-a-proxy.aspx
Using PsExec from Sysinternals
PsExec.exe -i -u "NT Authority\System" cmd.exe
will open a command prompt under the Local System account and you can run your scripts there and see their output. I tried that before using the runas command but it was always asking for a password what I do not have and I do not have to have it anymore. Less password = easier life.
To run a script under the Local System account I used to create a scheduled task to execute the script. It is working but troubleshooting is a little tough because you do not see the console output.
Recently I came across this article http://blogs.msdn.com/b/beanexpert/archive/2015/06/11/azure-ad-application-proxy-connector-connectivity-issues-with-a-proxy.aspx
Using PsExec from Sysinternals
PsExec.exe -i -u "NT Authority\System" cmd.exe
will open a command prompt under the Local System account and you can run your scripts there and see their output. I tried that before using the runas command but it was always asking for a password what I do not have and I do not have to have it anymore. Less password = easier life.
Friday, May 29, 2015
Microsoft Azure MFA authentication options
Microsoft Azure MFA and the equivalent for the on-premise installation is coming with 3 options for user verification:
- MFA service calls the user's phone
- MFA service sends a text message (aka SMS)
- Use of a MFA app on you mobile phone
So which option should we allow users to use and why?
Thought #1: The most generic and reliable option, and the option which can even be used with a landline phone is the option to give the user a call.
Thought #2: Send a text is more silent as option 1 and typically all cellphones can receive text messages while landline phones can't. If you are a global organisation and have users in different countries with different wireless providers you will may encounter that text messages sometimes need a long time before they arrive and sometimes they just silently disappear. So that needs to be considered.
Thought #3: The only solution which does not require a wireless signal to receive a call or text is the MFA app. But it requires a smart phone. I am very often in data centers and the cell phone reception is usually bad there, not just because of the noise. So I prefer using the app.
In general users should not be trained like a Pavlov's dogs to just accept phone calls without listening anymore because the get 500 calls per day. so use MFA wisely.
In conclusion all methods have pros and cons, but might for end users the phone call verification is the best, it can be for admins the smart phone app.
- MFA service calls the user's phone
- MFA service sends a text message (aka SMS)
- Use of a MFA app on you mobile phone
So which option should we allow users to use and why?
Thought #1: The most generic and reliable option, and the option which can even be used with a landline phone is the option to give the user a call.
Thought #2: Send a text is more silent as option 1 and typically all cellphones can receive text messages while landline phones can't. If you are a global organisation and have users in different countries with different wireless providers you will may encounter that text messages sometimes need a long time before they arrive and sometimes they just silently disappear. So that needs to be considered.
Thought #3: The only solution which does not require a wireless signal to receive a call or text is the MFA app. But it requires a smart phone. I am very often in data centers and the cell phone reception is usually bad there, not just because of the noise. So I prefer using the app.
In general users should not be trained like a Pavlov's dogs to just accept phone calls without listening anymore because the get 500 calls per day. so use MFA wisely.
In conclusion all methods have pros and cons, but might for end users the phone call verification is the best, it can be for admins the smart phone app.
Fiddler and TLS 1.2 support
After all the issues we have seen in the last year with SSL/TLS a lot of web applications have already disabled SSL entirely and started using TLS 1.2.
Therefore I want give an update on my Fiddler post:
http://secattic.blogspot.com/2012/10/1-2-3-see-what-is-in-saml-response.html
Fiddler2 cannot handle TLS 1.2 traffic, so you should upgrade to Fiddler4.
In short Fiddler4 is using the .Net Framework 4 which can handle TLS 1.2 traffic while framework 2.0 cannot.
see also, just select the different framwork versions and see yourself.
https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.110).aspx
Therefore I want give an update on my Fiddler post:
http://secattic.blogspot.com/2012/10/1-2-3-see-what-is-in-saml-response.html
Fiddler2 cannot handle TLS 1.2 traffic, so you should upgrade to Fiddler4.
In short Fiddler4 is using the .Net Framework 4 which can handle TLS 1.2 traffic while framework 2.0 cannot.
see also, just select the different framwork versions and see yourself.
https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.110).aspx
Friday, May 8, 2015
Microsoft Ignite - Identity Manager
Reviewing this week being at the Ignite conference I can say I was there because of the presentations Mark Wahl (http://goo.gl/yY0unq) has given about Identity Management. Here the highlights:
- Microsoft Identity Manager 2016 is still coming mid-year 2015 (actually the technical preview from April is saying 2015, but all new server apps are 2016 versions)
- Privileged Access Management (PAM, don't be confused with the Unix PAM - Pluggable Authentication Module) is integrated
- MS will not provide management agents for MIM for all SaaS applications as they provide that as functionality in Azure AD
- Cloud password reset will be supported only through the new Azure AD connect tool (you can think about it as Dirsync with more features) not through the FIM or MIM Azure AD management agent
- MIM certificate management works completed without ActiveX controls. The new Internet Edge web browser in Windows 10 - aka Spartan web browser - will cut the support for ActiveX controls anyway
- time-limited groups managed by MIM
- in-place upgrade from FIM 2010 to MIM 2016 is supported (no major changes e.g. no API changes)
Your are welcome to see the presentations on Channel9:
http://ignite.microsoft.com/session/sessionmoreinfo/?topicid=518ea07c-58a2-e411-b87f-00155d5066d7
http://ignite.microsoft.com/session/sessionmoreinfo/?topicid=f859bbd9-8ab0-e411-b87f-00155d5066d7
- Microsoft Identity Manager 2016 is still coming mid-year 2015 (actually the technical preview from April is saying 2015, but all new server apps are 2016 versions)
- Privileged Access Management (PAM, don't be confused with the Unix PAM - Pluggable Authentication Module) is integrated
- MS will not provide management agents for MIM for all SaaS applications as they provide that as functionality in Azure AD
- Cloud password reset will be supported only through the new Azure AD connect tool (you can think about it as Dirsync with more features) not through the FIM or MIM Azure AD management agent
- MIM certificate management works completed without ActiveX controls. The new Internet Edge web browser in Windows 10 - aka Spartan web browser - will cut the support for ActiveX controls anyway
- time-limited groups managed by MIM
- in-place upgrade from FIM 2010 to MIM 2016 is supported (no major changes e.g. no API changes)
Your are welcome to see the presentations on Channel9:
http://ignite.microsoft.com/session/sessionmoreinfo/?topicid=518ea07c-58a2-e411-b87f-00155d5066d7
http://ignite.microsoft.com/session/sessionmoreinfo/?topicid=f859bbd9-8ab0-e411-b87f-00155d5066d7
Wednesday, May 6, 2015
Microsoft Ignite - Federation Services and Publish Applications
I am at the Ignite again. Tuesday was the day for application publishing and AD Federation Services for me.
I just want focus on the main points:
AD FS
- AD FS 3.0 is using OAuth2 as the strategic protocol (reasons: platform support much broader, no api pre-requisited, always a web logon experience (consent to use app, MFA integration))
- AD FS 3.0 will allow other LDAP servers as authentication system
Web Application Proxy Service:
- strategically seen from Microsoft as the successor of UAG and TMG
- Features will be first introduces in Azure AD and then later also be available with the new Windows Server 2016
- The WAP service on Azure requires the install of a small agent on one of your on-premise servers. Interesting is that this client requires only outgoing traffic but no incoming ports. Is that a relief for you or does it scare you? What will your Information Security team think about that? Do they think about it like about a Trojan Horse, possible. So get prepared for their questions.
- The WAP connector can be installed on multiple machines to provide fault-tolerance and load-share. Microsoft has plans to allow to have connectors in multiple locations and to bind URLs to a specific connector, e.g. you run a app in a co-location and all others in you main datacenter.
- Microsoft will also add better monitoring and logging to the WAP service. Right now troubleshooting is very limited.
So if you ask me, the Web Application Proxy service in Azure is they way to go. And if you see how easy it is to configure it, you probably do not want go back to the old days with UAG and TMG.
btw: WAP is used from Microsoft as acronym for Windows Azure Pack and Web Application Proxy, so don't get confused. Here it is all about the Web Application Proxy
If you want watch the sessions online go here
http://channel9.msdn.com/Events/Ignite/2015/BRK3867
and
http://channel9.msdn.com/Events/Ignite/2015/BRK3864
I just want focus on the main points:
AD FS
- AD FS 3.0 is using OAuth2 as the strategic protocol (reasons: platform support much broader, no api pre-requisited, always a web logon experience (consent to use app, MFA integration))
- AD FS 3.0 will allow other LDAP servers as authentication system
Web Application Proxy Service:
- strategically seen from Microsoft as the successor of UAG and TMG
- Features will be first introduces in Azure AD and then later also be available with the new Windows Server 2016
- The WAP service on Azure requires the install of a small agent on one of your on-premise servers. Interesting is that this client requires only outgoing traffic but no incoming ports. Is that a relief for you or does it scare you? What will your Information Security team think about that? Do they think about it like about a Trojan Horse, possible. So get prepared for their questions.
- The WAP connector can be installed on multiple machines to provide fault-tolerance and load-share. Microsoft has plans to allow to have connectors in multiple locations and to bind URLs to a specific connector, e.g. you run a app in a co-location and all others in you main datacenter.
- Microsoft will also add better monitoring and logging to the WAP service. Right now troubleshooting is very limited.
So if you ask me, the Web Application Proxy service in Azure is they way to go. And if you see how easy it is to configure it, you probably do not want go back to the old days with UAG and TMG.
btw: WAP is used from Microsoft as acronym for Windows Azure Pack and Web Application Proxy, so don't get confused. Here it is all about the Web Application Proxy
If you want watch the sessions online go here
http://channel9.msdn.com/Events/Ignite/2015/BRK3867
and
http://channel9.msdn.com/Events/Ignite/2015/BRK3864
Subscribe to:
Posts (Atom)