The title gives it away. I'm trying to get this to work myself but there are some hurdles. My biggest problem is to troubleshoot the steps involved in getting autoenrollment to fire on a client not joined to the domain. I have it configured, but it does not trigger for certs nearing the end of life :( PS: I get "autoenroll" (user input trigger) to work for the user logget onto the non-domain-joined machine (setting CEP for user). There seems to be no trigger for the machine cert part though.

So got it to trigger, though it does not seem as the machine account manages to use the credentials that where bound when first the CEP was configured. The same goes for when it tries to trigger CES for the actual renewal. Error: Provider could not performe the action since the context was acquired as silent 0x80090022

So got it to trigger, though it does not seem the machine account manages to use the credentials that where bound when first the CEP was configured. The same goes for when it tries to trigger CES for the actual renewal. Error: Provider could not performe the action since the context was acquired as silent 0x80090022

Update 2: So got this to work for a non-domain-joined computer, machine certificate renewal triggered with a reboot near the end time for the certificate. Renewal used the bound credentials and, certificate renewal was done without user intervention. Now just need to test if this also works using certificate authentication, and that autorenewal also triggers in this senario.

I'm looking into this in the context of using SCCM in native mode with clients roaming the Internet. This will be no good if we can not address the problem of certificates expiering without the possibility of renewal. For this to happen they need to connect to corp net (VPN might do...). There are some policy files in C:\ProgramData\Microsoft\Windows\X509Enrollment for computer and C:\Users\<currentuser>\AppData\Local\Microsoft\Windows\X509Enrollment for the user you can edit with a XML editor. These files can freely be manipulated. I managed to add templates the computer did not hava access rights to and target the computer to use a specific URI for enrollment. So I could manage to enroll a computer certificate using a domain user instead of the default behaviour. This is only relevant if you are using GPO to push CEP policies. I am now trying to find out where on the machine the connection to what URL was used in the initial enrollment of the computer certificate is stored. In the hopes to be able to manipulate it to use a different URL for the rest of the lifecycle. Good luck finding your way, I will report back if I manage to get somewhere. Mind I have had this case open for some time, so I dont have high hopes. Morten

For 802.1X and domain joined computers you can use the legacy autoenroll/renew by only introducing the Kerberos URI in CEP&CES. As long as your clients boot up on your corp net once in a while the normal process of autorenewal will kick inn. You then dont need the UserName/password URI.

Hi, Lerun, Could you provide some more details regarding the configuration you used to get both user certificates and computer certificates to enrol and renew automatically? I have a lab setup that works for straightforward manual enrolment on non-domain joined computers. I have the authentication type set to Username/Password, but noted on the AskDS blog (http://blogs.technet.com/b/askds/archive/2010/05/25/enabling-cep-and-ces-for-enrolling-non-domain-joined-computers-for-certificates.aspx?wa=wsignin1.0) that there was a comment that stated the following regarding the need to disable the 'Enable for automatic enrolment and renewal' setting: NOTE: Failure to do so (disable the setting) could cause users to be prompted for user name and password each time they logon to the computer. This occurs because Windows Autoenrollment runs immediately after the user has logged on. If the enrollment policy is configured for automatic enrollment and renewal, Windows Autoenrollment will attempt to contact the configured CEP server when it starts in order to determine if new certificates have been assigned. Since this will result in the users being prompted for credentials every time they log on your users may be annoyed. Are you using Username/Password authentication? Do you have the issue described above? If so have you found a workaround for being prompted each time at logon? Steve G

Hi Steve I will try to elaborate some. On a bit separate note, I am currently trying to address the lack of functionality in the CertificateServiceClient component when it comes to all things auto (renew, enroll) with MS Support. I am still climbing the support chain, and am currently on a escelation engineer in Europe. I do not know how high I have to climb to be able to get someone that can talk with the product team or can look into the code and see what is happening there. The biggest lack I see currently is what I talk about in 1, if only the code would try to use all the CES URI when renwal triggers one could use the Kerberos URI for initial autoenroll and UserName URI in AllowRenewalOnly mode as a fallback when the computer/user is roaming the Internet. So there are two important things that needs to have been done to get certificates to auto-renew (just tested this for the local computer certificate store on a non-domain-joined computer). 1. When enrolling the certificate you have to use the UserName/Password URL for CES. The reason seems to be that the CertificateServiceClients remembers what URL was used for enroll and will only try the same when it is time for renewal (it will not fallback to the other URLs you may have added in AD, like Kerberos or Cert). 2. You need to bind username/password to the used URL (UserName/Password) for CES. This is using the Credential Manager functionality on Win7 on the local computer you are enrolling the certificate to. Either with also ticking the box for remembering credentials when prompted to enroll the certificate for the first time or going into Credentials Manager and make a new entry for the CES UserName/Password URL there. The user credentials used have to have enroll rights on the certificate template you wish to use. I have not gone in deepth yet when it comes to the relationship between user session context and computer session context (session 0). When I testet my user was local admin, and binding the credentials seems to make them available to both logged on user and computer context when it comes time for the CertificateServiceClient to try renewal. I am using a type Service Account that only have access to a subset of certificate templates. From a security perspective you can not hinder others from enrolling new certificates with this user; this could have been done if the UserName/Password URI was in AllowRenewalOnly mode. But one can only enter a given CES URI one time (and one would need the unresticted UserName/Password URI for the first enroll of the certificates). When changing CES URLs use: certutil -enrollmentServerURL URL Auth Pri AllowRenewalOnly certutil -enrollmentServerURL https://CESProxy.contoso.com/CA_CES_UsernamePassword/service.svc/CES UserName 1 0 This would add URI for username give it a priority of 1 and disable AllowOnlyRenewal mode. Regards Morten certutil -enrollmentServerUR

Hi, Morten, Many thanks for the comprehensive reply, it was very interesting. I'm still in lab mode with much of my research, which is primarily aimed at allowing employees to bring their own devices and connect them to the corporate LAN through 802.1x. Good luck with the support escalation. If there's anything you can share as a result of the escalation, I'd be very interested to hear. Steve G