Integrating Active Directory with Mobile Devices
-
@scottalanmiller said:
I think most people are not happy with that. Phones are "assigned by hardware" but the AD is "assigned by user." So you'd get a weird mix of user and device authentication on the device. Instead of calling a person, the phone number would be "call the anonymous user of this device."
The phone number is connected to the SIM card not the phone. So I could use any phone, and the phone could be multi-user, and I'd just have to plug my SIM into whichever phone I happened to be using at the time.
-
@Carnival-Boy said:
The phone number is connected to the SIM card not the phone. So I could use any phone, and the phone could be multi-user, and I'd just have to plug my SIM into whichever phone I happened to be using at the time.
If you are on a SIM service (GSM.) With Verizon or Spint, it is hard codes to the device. But yes, in theory, you can have an AD account and a disconnected SIM card that you use. So you end up with two access mechanisms for logging in rather than one. Isn't that an improvement?
-
@scottalanmiller said:
@Carnival-Boy said:
I mean define for the purposes of this thread. As in explain to non-technical people like me what the difference is. Though joining a Commodore 64 to a domain would be pretty cool.
It would be... but the C64 fundamentally doesn't have a concept of "users." So it's not like convincing a Mac or Linux box to join AD. They have users, just need to match them up and support the protocol. C64 and pretty much any home use OS prior to Windows 2000 lacked multi-user capability and could never use AD no matter what was added to it.
That's where the phone OSes are today. No users. Until they have users, the best that they could do, since they do have authentication, is tie to a single AD user account and support passwords via AD. But I doubt that that has value as it would only make them harder to support.
It took a long time to get there, but yes, this is what I want. A phone is NOT a multi user device - so the multi user facet of AD is not something I care about. If I'm controlling a device for my office - why should I have to pay for something else (MDM) to control it?
I'm not sure there is a name for the entire ecosystem that MS has created around access control/user authentication, etc - but I want that for the phones.
At least I think I do
-
@Dashrender said:
I'm not sure there is a name for the entire ecosystem that MS has created around access control/user authentication, etc - but I want that for the phones.
There is no ecosystem, it is just AD. Phones don't have users, so they can't tie to AD. You want people to have to enter a username and password to get into their phones? Why? What about this is better rather than worse than what you have today?
-
@Dashrender said:
It took a long time to get there, but yes, this is what I want. A phone is NOT a multi user device - so the multi user facet of AD is not something I care about.
But that is the ONLY facet of AD. What do you want AD to do then if not the one thing that it does?
-
@Dashrender said:
If I'm controlling a device for my office - why should I have to pay for something else (MDM) to control it?
Because AD offers NO control. If you are seeking control, AD should not be in the discussion. That's where this is getting confusing. If you want control of a mobile device, whether AD is there or not, you need MDM.
So if we fully integrate AD, 100%, you get nothing that you actually want and just make logins harder. MDM is still another step that you will still need.
-
Here is the easy way to think about AD integration. Replace saying AD with "I was username and passwords on phones that require a VPN back to the office to work rather than people being assigned to a phone and signing in with whatever security is standard for that device."
If that's what you want, I'd say "why", but maybe there is a good reason. But don't say AD, everyone is confused about what AD means. So replace the term with what it would mean in this context and ask if that is what you want - usernames and passwords on mobile devices that fail if the device can't get on a stable data network and connect to AD via a VPN. If that isn't what you want, don't say that AD brings a benefit.
I'm pretty sure everyone agrees that AD is bad for mobile devices but isn't clear what AD is and keeps thinking that there must be some upside somewhere.
-
@scottalanmiller said:
@Dashrender said:
I'm not sure there is a name for the entire ecosystem that MS has created around access control/user authentication, etc - but I want that for the phones.
There is no ecosystem, it is just AD. Phones don't have users, so they can't tie to AD. You want people to have to enter a username and password to get into their phones? Why? What about this is better rather than worse than what you have today?
because it's not centrally managed.
-
@Dashrender said:
because it's not centrally managed.
Because "what" is not centrally managed? What exactly is the end result that you desire?
Remember AD does not provide central management. So if that is what you seek, why are we talking AD? Central management for a mobile platform is called MDM.
-
I want to use Microsoft Group Policy (rather than, say, Meraki Group Policy) to control my phones. I also want single sign-on to AD so I can use the users AD account to authenticate phone apps to our server apps without them having to keep entering their account details.
I may be using Group Policy and AD interchangeability, but that's probably because you can't have Group Policy without AD, right?
-
@Carnival-Boy said:
I want to use Microsoft Group Policy (rather than, say, Meraki Group Policy) to control my phones.
That's a decent idea, but isn't AD that you want. GP is a different thing that leverages AD in some cases. So what we want is phone platforms to have a management API? That makes total sense to me. But, all of them already do. To leverage a phone management API, MDM is what that is called.
-
@Carnival-Boy said:
I may be using Group Policy and AD interchangeability, but that's probably because you can't have Group Policy without AD, right?
Yes, everyone is mixing those. And yes, they are independent. Every Windows machine has GP with or without AD. They can work together, but they are completely separate.
-
@Carnival-Boy said:
@scottalanmiller said:
I think most people are not happy with that. Phones are "assigned by hardware" but the AD is "assigned by user." So you'd get a weird mix of user and device authentication on the device. Instead of calling a person, the phone number would be "call the anonymous user of this device."
The phone number is connected to the SIM card not the phone. So I could use any phone, and the phone could be multi-user, and I'd just have to plug my SIM into whichever phone I happened to be using at the time.
The Top Cell carriers in the US use CDMA not GSM.
-
@scottalanmiller said:
@Carnival-Boy said:
I may be using Group Policy and AD interchangeability, but that's probably because you can't have Group Policy without AD, right?
Yes, everyone is mixing those. And yes, they are independent. Every Windows machine has GP with or without AD. They can work together, but they are completely separate.
You can join windows to a SAMBA domain without any Domain Group policy but, it will still do Authentication.
-
@thecreativeone91 said:
The Top Cell carriers in the US use CDMA not GSM.
Oh right. I've never heard of that.
-
@thecreativeone91 said:
The Top Cell carriers in the US use CDMA not GSM.
That is completely off base.
#1 Verizon uses CDMA.
#2 & #3 AT&T and T-Mobile use GSM.Then below that are US Cellular & Sprint using CDMA. US Cellular uses CDMA in order to claim good coverage because they have a no charge (to the consumer) roaming agreement with Verizon.
-
@thecreativeone91 said:
@Carnival-Boy said:
@scottalanmiller said:
I think most people are not happy with that. Phones are "assigned by hardware" but the AD is "assigned by user." So you'd get a weird mix of user and device authentication on the device. Instead of calling a person, the phone number would be "call the anonymous user of this device."
The phone number is connected to the SIM card not the phone. So I could use any phone, and the phone could be multi-user, and I'd just have to plug my SIM into whichever phone I happened to be using at the time.
The Top Cell carriers in the US use CDMA not GSM.
CDMA is moving toward CIM card usage.
http://s4gru.com/index.php?/topic/4635-will-sprint-now-be-moving-to-sim-based-authentication-for-cdma/Verizon already has it - my boss' CIM died last week and they had to send her another one.
-
OK - after a live chat with Scott I finally understand why INTEGRATED AD on the phones isn't really helpful. It's because phones don't talk directly to any of our AD authenticated equipment. Instead they use other solutions like ODfB or O365. These other solutions while perhaps being synced back to our internal AD's have their own authentication for which we have to put in our usernames/passwords.
For example - on our PCs we type 'net use s: \server\sharename' to map a drive through SMB - but this is something we never do on a phone. So the 'simplicity' of having our phone know our Username/Password already isn't really that helpful. (though because the phone could 'assume' the use of this information for setting up things like Sharepoint and O365 - it's not entirely non-useful either).
OK fine - Now I do want MDM control added to Windows just like Group Policy for Desktop/Laptops is part of Windows.
-
@Carnival-Boy said:
@thecreativeone91 said:
The Top Cell carriers in the US use CDMA not GSM.
Oh right. I've never heard of that.
Oh yeah, forgot that you would not be aware that SIM cards aren't exactly uncommon, but aren't the most common option here. And when you do have SIM cards, typically they are locked to the carrier and device, so only kinda of portable.
-
@Dashrender said:
OK - after a live chat with Scott I finally understand why INTEGRATED AD on the phones isn't really helpful. It's because phones don't talk directly to any of our AD authenticated equipment. Instead they use other solutions like ODfB or O365. These other solutions while perhaps being synced back to our internal AD's have their own authentication for which we have to put in our usernames/passwords.
You can think of this as "service level AD integration" instead of "OS level AD integration." Every service on my phone that could use AD already uses AD. The only thing that doesn't is the phone itself, which I don't want to.
