Updates for RMS in Windows 2012
- stronger key encryption (RSA 2048 SHA256) - patch available for Windows 2008 R2
- Logging is not using MSMQ anymore, writes straight to the database. Sounds like a little bit more overhead for logging but lessen the time for troubleshooting MSMQ
- As a result of the new server manager you can install RMS cluster from a single console
- RMS cluster servers can be core servers, installed from a server with full server version -OR-
- install RMS running the server gui and then switching to core server (switching between core and full is a new feature in Windows 2012)
- Delegation for e-mail protection, so the assistant can read the e-mail sent to the manager - available as patch for Windows 2008 R2
Tuesday, May 1, 2012
Monday, April 30, 2012
TEC2012: Windows 2012 Dynamic Access Control
Dynamic Access Control is a new feature in Windows Server 2012 (aka Windows 8).
It gives you:
- centralized policies
- rules to define attributes on user object, device object and resource object
user.departement == "HR" and device.managed=true and file.department=="HR" -> allow access
So if a user logs from manged machine in the office her/she can access that data, if he/she trys to access the data from their home computer he/she will get an access denied error.
Btw: the Acess Denied error dialog got some improvements as well, so the user can now request access from the dialogue. Let's see if the FIM product group is implementing this into the group membership management as well.
Dynamic Access Control is a integrated feature with Windows Server 2012.
http://technet.microsoft.com/en-us/library/hh831717.aspx
It gives you:
- centralized policies
- rules to define attributes on user object, device object and resource object
user.departement == "HR" and device.managed=true and file.department=="HR" -> allow access
So if a user logs from manged machine in the office her/she can access that data, if he/she trys to access the data from their home computer he/she will get an access denied error.
Btw: the Acess Denied error dialog got some improvements as well, so the user can now request access from the dialogue. Let's see if the FIM product group is implementing this into the group membership management as well.
Dynamic Access Control is a integrated feature with Windows Server 2012.
http://technet.microsoft.com/en-us/library/hh831717.aspx
Monday, December 19, 2011
Office 365: Rich coexistence failure because DirSync cannot write back to local AD
DirSync makes it very easy to populate all user account etc from the internal AD to Office 365. Error during exporting and syncing user data are reported via emails, so you can follow up on that.
For rich coexistence DirSync writes certain attributes back to AD, e.g proxyaaddresses.
Errors are not reported and you have to find them in the DirSync's "unofficial" UI.
If you see there "Insufficient access rights to perform the operation.” then the user MSOL_AD_SYNC does not have permissions to write those attributes.
This can happen because you assigned permissions on the user level and you have disabled the "include inheritable permissions from this object's parent" option.
From there you have two options; enable the option to use inheritance or add the permissions manually to each account.
For rich coexistence DirSync writes certain attributes back to AD, e.g proxyaaddresses.
Errors are not reported and you have to find them in the DirSync's "unofficial" UI.
If you see there "Insufficient access rights to perform the operation.” then the user MSOL_AD_SYNC does not have permissions to write those attributes.
This can happen because you assigned permissions on the user level and you have disabled the "include inheritable permissions from this object's parent" option.
From there you have two options; enable the option to use inheritance or add the permissions manually to each account.
Office 365: Off-boarding a mailbox
On-boarding a mailbox to Office 365 is a quite simple to do with the Exchange Management Console. But how to off board a mailbox. So you might ask why should I do that, well just to be prepared, just in case you have to.
First create a powershell session to O365:
$cred365= Get-Credential
$CloudSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/
Import-PSSession $CloudSession -Prefix 365
Now run the move request:
New-365MoveRequest -Outbound -Identity 'user@domain.com' -RemoteHostName mail.domain.com -TargetDeliveryDomain domain.com -RemoteCredential $credOnP -RemoteTargetDatabase 'Mailbox Database 041637xxxx'
Afterwards you can find the new move request in EMC under your Office 365 tenant in "Move requests".
First create a powershell session to O365:
$cred365= Get-Credential
$CloudSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/
Import-PSSession $CloudSession -Prefix 365
Now run the move request:
New-365MoveRequest -Outbound -Identity 'user@domain.com' -RemoteHostName mail.domain.com -TargetDeliveryDomain domain.com -RemoteCredential $credOnP -RemoteTargetDatabase 'Mailbox Database 041637xxxx'
Afterwards you can find the new move request in EMC under your Office 365 tenant in "Move requests".
Saturday, November 19, 2011
Office 365 DirSync 64bit based on FIM 2010
Office 365 for 64bit servers (2008 and 2008 R2) is here.
http://community.office365.com/en-us/w/sso/555.aspx
Still best practice is to have at least one of those servers for a setup with federated identities and Exchange rich-coexistence:
- ADFS server (plus ADFS proxy oder TMG or similar)
- DirSync server
- Exchange 2010 Hybrid server
btw: If you try to install DirSync 64bit on a Windows 2008 R2 DC you will see this message.
And it has still the same "scary" error about MSOLCoExistence registry key. Run the config wizard with elevated rights.
http://community.office365.com/en-us/w/sso/555.aspx
Still best practice is to have at least one of those servers for a setup with federated identities and Exchange rich-coexistence:
- ADFS server (plus ADFS proxy oder TMG or similar)
- DirSync server
- Exchange 2010 Hybrid server
btw: If you try to install DirSync 64bit on a Windows 2008 R2 DC you will see this message.
And it has still the same "scary" error about MSOLCoExistence registry key. Run the config wizard with elevated rights.
Error: Access to the registry key 'HKEY_LOCAL_MACHINE\Software\Microsoft\MSOLCoExistence' is denied.
Monday, November 14, 2011
Do I need a OCSP responder?
OCSP - Online Certificate Status Protocol
I was thinking about the question, why and when should I add OCSP for a PKI. And I see a lot of points why smaller organizations might not have a need for OCSP and large companies not necessarily.
- with Windows 2008 R2 OCSP uses the CRL as data set. So you must issued fresh CRLs more often.
- if you do not revoked certificates or have a alternative method to block access to your service, e.g. disable the user account in AD, then OCSP is only overhead. Review your revocation policy, if you dont have one - create one!
- Might not all of your clients "speak" OCSP (e.g. Windows 2000 and Windows XP)
- Check network connectivity from all your potential clients to the OCSP server, your clients talk on each certificate check back to OCSP. This can cause latency issues for your applications
- For e.g. Cisco concentrators you do not need to publish the OCSP path to all certificates, you can configure the OCSP path on the concentrator.
- Most clients cache the CRL locally, so if the CRL distribution point is not available for a short time, lets say 4 hours when your CRL validity is 2 weeks, still most of your systems would work without any issue. If you rely only on OCSP then make it high available.
- think also about additional license cost, operational costs and support
OCSP is a great improvement in environments with a high number of revokes, what means you have larger CRLs (in size). Unfortunately it is not easy to say when OCSP makes sense and when not, it highly depends how applications check for revocation status.
And OCSP is not a simple replacement for CRLs, it gives you more capabilities to manage certificate revocation. So it is more a logical extension of a PKI.
[Update] Google disables CRL and OCSP checks in the next Chrome version http://www.imperialviolet.org/2012/02/05/crlsets.html
---------------------------
Note 1: You can use 3rd party OCSP responder or clients as well to overcome Windows OCSP limitations.
Note 2: On Windows 2008 R2 Server Enterprise Edition is needed for each OCSP server installation.
I was thinking about the question, why and when should I add OCSP for a PKI. And I see a lot of points why smaller organizations might not have a need for OCSP and large companies not necessarily.
- with Windows 2008 R2 OCSP uses the CRL as data set. So you must issued fresh CRLs more often.
- if you do not revoked certificates or have a alternative method to block access to your service, e.g. disable the user account in AD, then OCSP is only overhead. Review your revocation policy, if you dont have one - create one!
- Might not all of your clients "speak" OCSP (e.g. Windows 2000 and Windows XP)
- Check network connectivity from all your potential clients to the OCSP server, your clients talk on each certificate check back to OCSP. This can cause latency issues for your applications
- For e.g. Cisco concentrators you do not need to publish the OCSP path to all certificates, you can configure the OCSP path on the concentrator.
- Most clients cache the CRL locally, so if the CRL distribution point is not available for a short time, lets say 4 hours when your CRL validity is 2 weeks, still most of your systems would work without any issue. If you rely only on OCSP then make it high available.
- think also about additional license cost, operational costs and support
OCSP is a great improvement in environments with a high number of revokes, what means you have larger CRLs (in size). Unfortunately it is not easy to say when OCSP makes sense and when not, it highly depends how applications check for revocation status.
And OCSP is not a simple replacement for CRLs, it gives you more capabilities to manage certificate revocation. So it is more a logical extension of a PKI.
[Update] Google disables CRL and OCSP checks in the next Chrome version http://www.imperialviolet.org/2012/02/05/crlsets.html
---------------------------
Note 1: You can use 3rd party OCSP responder or clients as well to overcome Windows OCSP limitations.
Note 2: On Windows 2008 R2 Server Enterprise Edition is needed for each OCSP server installation.
Friday, November 11, 2011
Office 365 password change for webmail-only remote users
Recently a question came across my mind about password change for remote users if they are only use OWA.
So might they work from home with their personal computer. A password change is then not enforced and a password change via CTRL-ALT-DEL will not change the AD password.
In a setup with federated identities those users will still see a URL for password change in OWA, but they cant access it. And of course they do not have a password on O365 at all (may a very long random password as we know it from Smart Card only users). So my idea was to search for a option to define a alternative URL, but no luck. MS Online confirmed that there is no option today to define such an URL.
Okay, so what. Let's go and a grab the IISADMPWD from Windows 2003 IIS and tell the user the new URL to change the password.I would like to have them changed their password every 43 days (or whatever) . IISADMPWD works, even it is not supported anymore, also with IIS 7. But I found one catch. If you are using a ADFS proxy server, which is usually not a domain member and located highly protected in a DMZ, then IISADMPWD cannot be used to change the AD passwords.
So might I can extend IISADMPWD with an web service running on the ADFS server. Lets see if I get this done before end of this year.
So might they work from home with their personal computer. A password change is then not enforced and a password change via CTRL-ALT-DEL will not change the AD password.
In a setup with federated identities those users will still see a URL for password change in OWA, but they cant access it. And of course they do not have a password on O365 at all (may a very long random password as we know it from Smart Card only users). So my idea was to search for a option to define a alternative URL, but no luck. MS Online confirmed that there is no option today to define such an URL.
Okay, so what. Let's go and a grab the IISADMPWD from Windows 2003 IIS and tell the user the new URL to change the password.I would like to have them changed their password every 43 days (or whatever) . IISADMPWD works, even it is not supported anymore, also with IIS 7. But I found one catch. If you are using a ADFS proxy server, which is usually not a domain member and located highly protected in a DMZ, then IISADMPWD cannot be used to change the AD passwords.
So might I can extend IISADMPWD with an web service running on the ADFS server. Lets see if I get this done before end of this year.
Subscribe to:
Posts (Atom)