Maybe some of following statement are not accurate, but in overall, it works very similarly.
It really depends on implementation. But the idea is the private key never leaves the device it is using it. If so it is wrong design. I don't know any MDM (mobile device management software) as I didn't work with any previously but it will work in very similar way as I describe bellow.
The mobile device (iPhone in your case) will generate private key. It will also create the CSR (certificate signing request - it out of other data includes public part of the generated key), please note the CSR can also be generated by the MDM then delivered to iPhone for signing. Then iPhone signs it (hashes it and encrypts the hash) using the generated private key and send it over the MDM to CA (certification authority) for validation and approval. MDM is responsible for device authentication before the first key is generated, I would say you need to login using AD user name/password for the first time from trusted network without any authentication method, such as 802.1x.
Once the CA will ensure the validity of CSR (this can be also completely manual process) it creates the certificate and signs the certificate using its private key. It stores generated certificate to issued certificates store and passes it back to the MDM. MDM will store it in AD (or not) and send it back to the iPhone device. Once device receives the signed certificate it checks if it has appropriate CSR stored inside (it should as it generated / signed it), pairs the information from signed cert and CSR together and store the certificate including the public and private parts of the key internally (usually to secure certificate store). Private key can be additionally protected using some kind of another protection (i.e. PIN, password, smart card, whatever) so it user mus authorize usage of the key in such case. In iPhone I would say it is protected and encrypted using the user password/pin/fingerprint so once you unlock the phone it can be used.
For authentication, (it does not matter if it is 802.1x EAP-TLS or another TLS or another method using certificates for authentication - everything works similary) you use this certificate signed with CA and usually something signed (encrypted) by your private key related to the certificate. It is usually some kind of challenge sent by the server and it is used to proof you own the private key related to the certificate you sent to server to be used for authentication and you claim it is yours.
Server then checks your certificate (if it is valid - date/time, if it is not revoked, if it is supposed to be used to do the action you are actually trying to do and if it is signed with trustworthy certification authority) then it uses the public part of the key stored in the certificate to decrypt the challenge to make sure you are owner of the certificate (the correct private key was used to sign the data) If the decryption is successful and the challenge matches the challenge sent to you for signing it actually means you are the owner of the certificate and you own the private key related to that certificate.
So what the server needs to know to authenticate you? Just the root CA or immediate CA authority certificate used to sign your certificate, your certificate including your public part of the key and the data encrypted (signed) with your private key related to the certificate. That's enough to authenticate and authorize you. It never needs to know your private key so there is no reason to store it in AD or in CA or wherever else than in your device.
Few words about the AD and MS PKI (CA service) - its same as stated above :):
AD never stores your certificate including private key. Why? Because it simply does not know it. It never did. If you ask for certificate in MS PKI (others work in the same or very similar way - EJBCA, OpenCA...) it usually works in the way you generate the private key on your computer, then you create certificate signing request. This can be done at any place, in case of MS it is on the CA server self service usually. CSR contains i.e.: distinguished name (name or email), your address, what purposes you request the certificate for - ie. authentication, email signing, whatever). Then you get the CSR, and you add some info to it, i.e. public part of the key, fingerprints, whatever. Finally, you sign the CSR (you hash the CSR and you encrypt the hash using your private key) then you send it to the self CA service portal. CA then generates a cert, signs it and delivers it back to you in pre-defined way. I.e. by placing it on the web or by email or, it probably could be integrated with MDM also.
In this case I am not 100% sure the described process works like this in detail but it will be very very close to it.
