.mobileconfig and ADCertificatePayloadPlugin

I know 401 means not authorized, but as best as I can tell the workstations machine account in the domain is still active and has the appropriate permissions. I can login with my credentials. I can't enroll as a workstation since I'm not a workstation. I don't see that template available to me. I've had ~100 Windows 7 workstations successfully auto enroll via Group Policy in the last 24 hours. I can't think of any way to login with the machine account - is there a way to get Safari to do that?

Any other thoughts?

Thanks

-Matt

My apologies - I had (somehow) enabled the "Computer" certificate template in the web enrollment portal (by default you will not see it in the Certificate Templates list)...You may be able to do the same thing by following some of these steps: http://msdn.microsoft.com/en-us/library/aa381929%28v=vs.85%29.aspx ... To obtain a machine certificate, I believe that it would be necessary to perform the 'advanced' request, and provide the CSR generated with the host machine's DNS name specified as the common name (or name as showing in AD computers list).

Make sure that you're not trying to push the requests through a proxy server - from some basic packet analysis that I performed yesterday, I can see that the Mac is initially hitting the enrollment pages and receiving a 401 error (even when the certificate enrollment works correctly). At that point, I believe that it is negotiating authenticating using SPNEGO, submitting a base64 encoding of the machine's Kerberos ticket(?), and then submitting the CSR in a POST request. It may be possible to simulate these steps manually, but it might be somewhat difficult. There are some pretty good details regarding the negotiation on this page: http://msdn.microsoft.com/en-us/library/ms995330.aspx (under SPNEGO token handshake using HTTP headers).

No, from what I can seen, Safari is probably not going to be able to authenticate to the web enrollment portal as a machine.

Something rather odd on my setup - is that loginwindow setting. (I assume that gives the option of wireless above the username/password field)

If I set it to my Wifi Network (the name I used in the script file) and try to login, I can see in the top-right corner the wireless icon dim out, and come back on during the logon process. It usually means I cannot log in as the connection is lost during authentication of the user.

But if I set it to none, the connection remains solid at the login window, and remains connected after login.

So my question is, what's that connection used for (as the mac connects to the preferred / in-range network automatically), and if the airport is turned off, this box disappears anyway.

And if possible, can I remove this loginwindow box without having to re-run the entire profile process? (I notice when I delete the profile, it also kindly deletes my certificates)

It seems to be something different when authenticatiing the machine, compared to the user.

Computer:

Network Policy Server granted full access to a user because the host met the defined health policy.

User:

Security ID: DOMAIN\computer_25$

Account Name: host/computer_25.DOMAIN.local

Account Domain: DOMAIN

Fully Qualified Account Name: domain.local/Container/computer_25

Authentication Details:

Connection Request Policy Name: Secure Wireless Connections

Network Policy Name: Wireless Mac's

Authentication Provider: Windows

Authentication Server: nas.domain.local

Authentication Type: EAP

EAP Type: Microsoft: Smart Card or other certificate

Account Session Identifier: -

User:

Network Policy Server denied access to a user.

User:

Security ID: DOMAIN\test

Account Name: test

Account Domain: DOMAIN

Fully Qualified Account Name: domain.local/Users/test

Authentication Details:

Connection Request Policy Name: Secure Wireless Connections

Network Policy Name: Connections to other access servers

Authentication Provider: Windows

Authentication Server: nas.domain.local

Authentication Type: EAP

EAP Type: -

Account Session Identifier: -

Logging Results: Accounting information was written to the local log file.

Reason Code: 66

Reason: The user attempted to use an authentication method that is not enabled on the matching network policy.

My question would be - can I configure the Mac's to not worry about user authentication during logon? I am happy with just machine authentication only.

(The same as GPO > Wireless 802.11 Policies > Profile > Security > Authentication Mode: "Computer Authentication" in windows.)

It could be that the test user has joined that wireless network in the past, which may have caused it to be saved as a favorite network in System Preferences -> Network -> WiFi...Removing it from the list of networks shouldn't stop the mobileconfig profile from doing its magic, but it might stop the system from attempting to re-authenticate to the access point when the user logs in (because their preferences are configured to do so).

It might also be good to remove any user credentials from the keychain (saved from previous authentication to that access point).

I found a solution that works and you can answer why (As I don't understand EAP Types)

I needed to add two network policies in NPS:

One conditioned to the Mac's only - Using Smart Card or Other Certificate

The second conditioned to the Mac's and the Users - Using Protected EAP

So prior to logon the Mac's use Other Certificate (TLS-EAP?) but during/after logon the Mac's are using PEAP and EAP-MSCHAPv2

I had both types in one policy assuming if it failed it would try the next, but it skips to the next policy.

So I am using different authorization types for the computer and user, but I am not on the PC's?

I managed to figure it all out 🙂

I have now resorted to PEAP-MSCHAPv2 domain wide until I can properly serve machine and user certificates across the domain.

I did purchase Mountain Lion server and created profiles which were much easier to implement and deploy - and it gives the option to export if I didnt want to use Open Directory, but at this stage, I think I will use Mountain Lion Server as well as AD.

Thanks for the help. Its been a steep learning curve the last few days!

So, I have been playing with this more with some success. I have multiple workstations running 10.7.5 that are unable to complete the request. I have, however, a brand new machine running Mountain Lion that completely the request with no issue (same script).

My most recent error was "profiles install for file:'caenroll.mobileconfig' and user:'(null)' returned -319 (The 'Active Directory Certificate' payload could not be installed. The certificate request failed.)" and this time I didn't even see the attempt logged on the ADCS server. Any thoughts? I can't find error -319 referenced anywhere when Googling for it.

Thanks!

It may help to enable verbose logging when using the 'profiles' command to import the profile...It should be possible to enable that logging by passing the "-v" flag when running the import command (e.g., 'sudo profiles -v -I -F /path/to/file.mobileconfig').

Ready for this? With the verbose flag it works! Tested on three machines now. Fails without verbose, succeeds with versbose turned on.

I don't understand it, but whatever. I have updated my script to use the verbose flag.

Thanks!

That's pretty odd...Enabling verbose output shouldn't allow the command to complete (where it failed without)...

When the script was failing, were you using 'sudo' when attempting to import the profile (without the verbose flag)?If not, you'd want to be sure to prefix the 'profiles' command with 'sudo' so that the command runs as a superuser (root).

If you were using 'sudo', and found that the only way to get the profile to import correctly was to append the verbose flag, it may be a bug (http://radar.apple.com)?

I also had the same 319 error but in my case it was the Mac's that were bound to Open Directory as well as Active Directory and it appeared that authentication was against OD instead of AD.

I think moving the authentication order so AD came first may have solved it for me, but in my case I removed OD as I dont need it to authenticate the Mac clients.

I believe that when using the Magic (Golden) Triangle, you should generally have the Active Directory domain (i.e., Kerberos realm) that you're authenticating to listed first in Directory Utility -> Search Policy -> Authentication -> Directory Domains. This should apply to all Mac clients (and servers?) in your domain. The best resource that I could find is on page 67 of this manual: http://manuals.info.apple.com/en_US/OpenDirAdmin_v10.6.pdf under "Integrating with a Magic Triangle".

Ok ... new related question. I have the AD CS template set the the private keys are not exportable. However, in Keychain the clients let me export the private key for the certificate from AD. Any way to set that the private key is not exportable?

My whole reason for doing machine certs and not user certs was to make sure the user couldn't move the cert to a non-authorized machine. This is defeated by this - one of them has already exported the private key and added the cert to their iPhone >:|

Thanks

-Matt

You can specify that private keys aren't exportable when importing them with the 'security' tool...I'm not sure why the ADCertificatePayloadPlugin wouldn't use this setting, but you may be able to get around this by performing an export/import of that key manually, and specifying that it is not exportable when re-importing:

sudo security import ~/Desktop/Certificates.p12 -k /Library/Keychains/System.keychain -t agg -f pkcs12 -x

The '-x' flag specifies that the private key cannot be exported...

To perform the import in this manner, you can go into Keychain Access -> System -> select the cert/key pair, go to File -> "Export Items...", export as '.p12', remove the item from the keychain (both the certificate and private key), and then perform a command similar to the one above (modify "~/Desktop/Certificates.p12" to match the path that you exported the keypair to). The '-t' flag specifies the certificate type - pkcs12 is an aggregate type (agg). The '-f' flag specifies the format (pkcs12 matches the .p12 format that you exported the items in).

Unfortunately, this is a little more of a process than you should be required to perform to secure keys that were already specified as non-exportable in AD policies. It may be possible to simply set the key as non-exportable without having to perform the import/export steps above, but I could not find that answer.