Integrating Active Directory with Mobile Devices
-
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.
-
@scottalanmiller said:
@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.
Great way to put it Scott.
-
@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.
That's good for you. We don't use ODfB or O365 so our phones do talk directly to our internal servers. Users have to manually enter their credentials to each and every server. A single sign-on, using a fingerprint, that then authenticates to all our servers would be helpful.
Also, an Apple phone has to authenticate to an Apple ID (a pain to administer), a Windows phone has to (or did when I had one) authenticate to a Microsoft ID (also a pain to administer). I don't know how Android works. Instead of authenticating to a unique Microsoft or Apple user ID, why can't I use a local domain account instead?
-
@Carnival-Boy said:
That's good for you. We don't use ODfB or O365 so our phones do talk directly to our internal servers. Users have to manually enter their credentials to each and every server. A single sign-on, using a fingerprint, that then authenticates to all our servers would be helpful.
How are your phones connecting to your internal severs - you mean like a web page?
Also, an Apple phone has to authenticate to an Apple ID (a pain to administer), a Windows phone has to (or did when I had one) authenticate to a Microsoft ID (also a pain to administer). I don't know how Android works. Instead of authenticating to a unique Microsoft or Apple user ID, why can't I use a local domain account instead?
What are you trying to administer with regards to these IDs?
FYI - Android by default wants to log into a google account, but you don't have to.
-
-
At the moment, all are web servers. Though the ability to browse network file shares would also be good - ie the net use S: you referred to earlier.
-
If I give a new user an iPhone, I have to create an Apple ID for him. As a result I have loads of Apple IDs. I could do without this. Especially the stupid "what was your favourite teacher at school?" type security questions.
-
-
@Carnival-Boy said:
- At the moment, all are web servers. Though the ability to browse network file shares would also be good - ie the net use S: you referred to earlier.
The built-in password manager for the web browser should be able to hold onto the passwords for the sites you visit. As for mapping a network drive, mobile platforms don't support the SMB protocol without an add-on app. That app can probably hold the credentials for the drives you want to map.
- If I give a new user an iPhone, I have to create an Apple ID for him. As a result I have loads of Apple IDs. I could do without this. Especially the stupid "what was your favourite teacher at school?" type security questions.
Having never setup an iPhone from scratch I didn't know an Apple ID was required. Do you need to make separate accounts for each device? A quick google search lead me to a recommendation that the company have one Apple ID on all devices for things like the Apple Store (assuming you want to prevent people from installing apps) and allow the users to create a second Apple ID based on say their work email address that they can use for iMessage, Facetime, etc.
-
@Dashrender said:
Having never setup an iPhone from scratch I didn't know an Apple ID was required. Do you need to make separate accounts for each device? A quick google search lead me to a recommendation that the company have one Apple ID on all devices for things like the Apple Store (assuming you want to prevent people from installing apps) and allow the users to create a second Apple ID based on say their work email address that they can use for iMessage, Facetime, etc.
This is what I have always done. all devices are on one ID. I always blocked iMessage, Facetime and buying of from the store from the MDM.
-
-
No option to store web server credentials when I've tested it on my iPhone. I'd like my mobile platform to support the SMB protocol. Why not?
-
I set-up a separate Apple ID for each user and use the user's e-mail address as the ID. I also use my e-mail address as the secondary e-mail, so I can use that to authenticate the new ID (which you need to do in order to configure the phone). I don't want to prevent people from installing apps - in fact I encourage it.
From a security point of view, I've no idea if this is a terrible idea. @scottalanmiller will admonish me for keeping a record of the Apple ID passwords. I guess it does get a big dodgy if they store their personal credit card details against the Apple ID, and I'd recommend they change the password or use their own Apple ID if that is something they intend to do. If it integrated with AD, I'd just reset the password - wouldn't that be cool?
-
-
@Carnival-Boy said:
- No option to store web server credentials when I've tested it on my iPhone. I'd like my mobile platform to support the SMB protocol. Why not?
Why do you want that? A phone/tablet isn't a computer. That's what cloud service apps/work folders/own cloud is for.
By doing that you are given a device you don't have a ton of control over the same trust as you would a computer you can control. It also means ANY app wanted or not can now access that share and potentially steal data.
-
It is a computer and I would have a ton of control over it because it would join AD.
