A friend was not receiving Facebook SMS two factor authentication codes on his iPhone. I removed all his blocked numbers and he received the code. We assume he accidentally blocked the number Facebook uses to send SMS codes.
You can see blocked numbers in Settings:Phone:Blocked Contacts (it's actually a list of blocked numbers, not a list of blocked Contacts). If iCloud sync is working you see the same list in Messages on macOS.
Apple's FairPlay DRM management is notoriously fragile. It can be confused by family sharing, Screen Time controls, payment method changes, and, heaven forfend, mixed Apple IDs on a device.
Once Apple's DRM gets confused there's often no user accessible error message (PS. This is a bug [1]). The app just hangs. So when I realized my (manual) App Store updates were not completing I was not completely surprised. Recently I had:
Someone who has your iPhone passcode can lock you out of your Apple iCloud and Apple ID services -- as well as take control of your iPhone and have access to all passwords stored in Apple's Password Manager (iCloud Keychain).
This can happen when someone steals your phone and obtains your passcode by the simple measure of threatening to kill you. Or they might see you enter your passcode or surreptitiously record entry. In bars drugs can be used to facilitate the process. This is often done as part of "borrowing a phone" for an "emergency call". (Never let anyone you don't trust with your life and wealth touch your phone. If it's an emergency make the call for them but ensure they don't record your passcode and don't let go of the phone.)
Once the thief has your phone and passcode they can change the victim's Apple ID password. This prevents the victim from locking the iPhone. The victim could still do the Apple ID password recovery process, so to get more time with the phone the thief can set a Recovery Key. If a Recovery Key exists they can change it. Setting a Recovery Key this way disables Apple ID password recovery. This gives the thief an unlimited time with the phone. It also locks the user out of all their Apple ID associated services and products including video, music, personal photos, personal documents, family sharing, other Apple devices, and the like. From the thief's perspective the Apple ID lock out is merely a side-effect. They may even feel a tiny qualm of sympathy for their victim. They do it to prevent iPhone lockout.
This is an Apple design problem. They need to fix it. Basically the iPhone passcode has far too much power -- especially since it has to be tapped in far too frequently and thus relatively easy to enter. Secondarily the benefits of the Recovery Key are limited to a few people and the with this technique in common use the risks dwarf the benefits. Apple should disable creation of new Recovery Keys immediately while they come up with a better fix.
TidBITS has one of the best descriptions of the problem following a somewhat confused WSJ article. I suggest also reading TidBITs preceding article on the problems with iCloud Keychain.
I was aware of most of these issues, but the Recovery Key hack is new to me. Again, if an attacker has control of your iPhone they can change your Apple ID password, locking you out of your photos, documents, Apple services, Apple media you've purchased, subscriptions, software, and more. At this point you can ordinarily reset your Apple ID password [1] through a tedious series of authentication steps or with the help of a previously specified Recovery Contact [2]. However, if you have set a Recovery Key you can't use these methods. You have to know the Recovery Key. If a thief sets or changes the Apple ID Recovery Key to prevent locking of the stolen iPhone you are truly screwed. Once you set the Recovery Key yourself Apple no longer stores it [3]; they can't recover your Apple ID even if they wanted to.
Apple has to fix several things here. It's insane that a six digit iPhone passcode allows access to all of the iCloud Keychain (Apple Password Manager) and setting up a Recovery Key. The power and risk of the Recovery Key is a separate problem and creation of new Recovery Keys should be disabled until there's a better fix.
In the meantime we've taken two steps on our our iPhones:
I do NOT recommend setting a Recovery Key. An attacker with your iPhone passcode can change it anyway, and you won't be able to use Apple's standard Apple ID password recovery method.
- fn-
[1] One time I tried to use login with Apple on a calendar service provider (Stanza). Apple evidently decided that was a bad idea and instantly locked my Apple ID. I had to follow the password recovering steps. If I'd set a Recovery Key and did not know the Key I'd have lost access to my Apple ID content (photos, etc) for all time.
[2] Setup a recovery contact NOW.
[3] I presume that when you do a standard password reset, or a Recovery Contact does a password reset for you, that behind the scenes Apple is using the Recovery Key they keep.
Send an email message to someone who is using Gmail or Google Workspace. (You can't verify DKIM is on by sending yourself a test message.)
In the message header, look for Authentication-Results. Receiving services use different formats for incoming message headers, however the DKIM results should say something like DKIM=pass or DKIM=OK.If the message header doesn't include a line about DKIM, messages sent from your domain aren't signed with DKIM.
When I looked at view original sent form Emily's account to my personal gmail account I didn't see DKIM=pass or DKIM=OK but I did see two entries starting with:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
More importantly when I scrolled up a bit (this is in Gmail View Original) I saw a header that's interpreting the email headers (I think this might be a newer feature):
Message ID ....
Created at: Mon, Mar 13, 2023 at 2:59 PM (Delivered after 12 seconds)
From: Emily ....
To: John ...
Subject: test DKIM content
SPF: NEUTRAL with IP ...
DKIM: 'PASS' with domain ...
You can also paste the "original message" headers into toolbox.googleapps.com/apps/messageheader/. That gave similar results.
When I tested on a second family domain that did NOT have DNS TXT entry for DKIM it showed as DKIM 'PASS" in the email header interpretation with an odd domain string -- BUT in Google Apps it showed as NOT authenticating. I cannot explain this.
Once I updated the DNS TXT DKIM entry for that domain and allowed a few minutes for propagation it did show in the Google Apps admin console as authenticating with DKIM and the headers showed the correct domain name.
DH's note on SPF records says they cannot be updated if we are using Google Workspace. This is new since 2018 and I think that's correct.
... Make sure that you're using the same Apple ID for Family Sharing and Media & Purchases...
They don't say how to migrate to that idea of course! Obviously it was possible to use a different Apple ID for Family Sharing and Media (Apple Music worked before). I don't know if the changes made to my device impacted any other family members (wish I'd checked!), but it appears for a Family Organizer device to see Apple Music they have to use the same Apple ID used at time of purchase.
Somewhat surprisingly Apple let me revert back to Sam/Linda on my iPhone. (I think there was some time limit/change limit on Apple ID media changes.) After a period of sync I had my old playlist and Apple Music access.
My guess is that to make the change to Sam/Sam and keep Apple Music I'll have to end my current subscription (tied to Linda) then change the Media Apple ID then resubscribe for the family. (In practice I'll end all subscriptions for Linda before the change.)
Based on some issues I've seen with my daughter's devices I think that Apple Message sync will only work when both Apple ID for "iCloud" and Apple ID for "Media & Purchases" agree on both devices.
There's a dependency on "Media & Purchases" Apple ID for Apple Messages, perhaps because it's descended from the Apple messaging apps that predate iCloud.
I'll provide some back story below, but it's tedious and a bit ranty so I'll put the most useful stuff up front.
For *reasons* (see below) I have had an Apple ID associated with iTunes, App Store, physical Apple Store, hardware and other purchases for about 20 years. For other *reasons* almost lost to memory the username has not been a valid email address for most of those years. Until recently it had an associated email address it would forward to but Apple changed things sometime in the past two years and that stopped working.
I'm simplifying.
We will call this Apple ID username "bob@mac.com". I will use alice@icloud.com and dan@me.com for my new Store Apple ID ("Media & Purchases") and my longstanding iCloud Apple ID respectively.
Once bob@mac.com stopped forwarding I no longer received notifications related to Apple Discussions or emails related to charges. Since bob@mac.com was the store Apple ID for my family (this was the practice in early iTunes days) our children (now adult) used it for purchases. Simplifying a lot and omitting family details the lack of email meant no monthly statements -- so I didn't spot a scam subscription - among other things.
I knew I had to fix this but I dreaded the side-effects. I'd already tried undoing the shared store Apple ID and ran into disaster; I had to reverse that attempt. I had to fix the Apple ID invalid email problem first.
Before Apple broke forwarding for the Apple ID "bob@mac.com" I had used "alice@icloud.com" as a forwarding address. Although there was no clue in the Apple ID online configuration tool, I knew alice@icloud.com was still entangled with bob@mac.com (see below, this post goes on for a long time but still omits much).
Ok, so far? I gets a bit simpler then you can skip the back story.
Anyhow ... when Apple broke forwarding they seem to have introduced the ability to change an Apple ID userid - such as bob@mac.com. I believe, though I can't find any documentation, that the visible username with the form of an email address (ex: bob@mac.com) is an alias for an unchanging hidden identifier (maybe a GUID).
After some thought I decided the cleanest approach would be to change my Store Apple ID visible username from bob@mac.com to alice@icloud.com (I knew the two were entangled, see below). It's easy to make this change from appleid.apple.com. When I did this I was not asked to confirm that alice@icloud.com was a valid email address I owned. All I got was an email sent to to alice@icloud.com saying the change had been made.
After I made the change I found the following. I expect other changes as Apple's different systems synchronize and update (I will update this as I learn more, I expect to learn of problems from family members later today):
Messages in iCloud not available as iCloud and iMessage accounts do not match. (Messages in iCloud is not available because iCloud and iMessage accounts are different.)
There's a fix here but it's not the one I needed. When I looked at Messages on my iPhone it showed only my Phone number, the Apple IDs were all absent. When I tried to enter an Apple ID it showed my store Apple ID; I chose "use other Apple ID" and entered my personal iCloud Apple ID. That worked and it immediately restored all my send/receive message list. I could then reenable messages in iCloud.
It didn't fully work on Mojave iMessages though. I reenabled using iCloud Messages in preferences there and about an hour or two later it seemed to start working (though uploading messages to iCloud is still ongoing.)
That concludes the current record of changes to date. So far it has been less of a problem than anticipated, but it's early days. I will add other issues as they emerge. Then I can return to the herculean tasks of moving family members off of a shared Media & Purchases account.
Below are details for the benefit of someone searching who finds this post. They are related older items that I will summarize in outline.
----------- additional details ---------------
As noted above years ago I had alice@icloud.com as forwarding email for the Apple ID bob@mac.com. The address bob@mac.com had no associated email because of complex changes Apple made in migrating from free iTools to not-free .Mac to MobileMe. [1][2]
When I finally realized I wasn't getting Apple media purchase statements for bob@mac.com I began investigating what had happened to the old alice@icloud.com iCloud account. I found it was deactivated. I was able to reenable it. That's when things got weird. Remember (if you read above) that there was no longer anything I the Apple ID settings for bob@mac.com that showed alice@icloud.com.
Once I reenabled alice@icloud.com with a new password I found that:
[2] eWorld https://en.wikipedia.org/wiki/EWorld
. Yesterday the password for App Store was different from password for Apple ID but today they seem to be same. I think they are two different systems that update every few hours...
· Feb 19
Today it appears there is a single Apple ID with two usernames and one password. One username has iCloud services but is nowhere displayed in Apple ID information. twitter.com/jgordonshare/s…
... If you change a phone's Store ID to match the phone's iCloud ID you cannot update all their apps with their iCloud ID password. You need to use the old Store ID password. Even when family sharing is in play...
... I have a hunch that Apple has an internal ID for users separate from the username (email form) displayed with their Apple IDs and Store IDs and iCloud IDs and that is what they use in FairPlay.
You can't change the date of birth or family relationship of an Apple ID with a calculated age of less than 13 years old. Otherwise it's supposed to be possible to change the date of birth associated with an Apple ID. I've done it before (for good reasons).
Recently I decided to get #2 child an Apple credit card. Since banks take birth dates seriously I decided I needed to correct his before applying. It didn't work!
This is what his birthday looks like on his Apple ID web page (same as in his iOS devices):
(You can skip the rant to get to the tech details)
<rant>I frequently berate Apple for the radioactive-feces-infested-dumpster-fire that they’ve built out of Family Sharing and Parental Controls / Screen Time / Restrictions [1] … but my latest experience has added a note of sympathy for the engineers who offend Tim Cook and are HR assigned to work on this prior to leaving Apple.
Apple has built something insanely complicated. The intersection of user interfaces, regional rules and restrictions, content licensing, DRM, functional requirements, iOS, macOS, iCloud, sync, multiple OS versions … heck, there probably time zones in there too. At this point they might as well give up and throw a neural network at it.
Whatever your day job, be grateful this isn’t what you work on.
Things are almost as bad on the consumer side. There’s a reason I seem to be the only person alive trying to make remote Screen Time work. (It’s a book project, I don’t have a choice.) With some effort I’ve come up with practical recommendations for caregivers (example) — but they assume the software actually functions. In practice I have run into a wide range of bugs and weirdness, particularly since iOS 13 was released.<rant>
Among the many complications Apple contends with into are rules about how many devices and how many users can be a part of a Family for the purposes of both DRM management and remote Screen Time. These are poorly documented, but as best I can tell the limit is 5 family members and somewhere around 10 devices (it’s not clear how multi-user accounts on macOS are treated or Apple TV). Our family has five members so we’re pretty much at the limit and I think we’re at the absolute device limit as well.
I say “think” because it’s not clear that there are error messages, I think things simply break.
So the baseline situation is pretty bad, even before one runs into bugs with handing down devices between family members.
I made things worse though. For a book project I added a test account — sphone4all@icloud.com. That pushed us up to six family members and probably hit or exceeded our device limit. Since my test phone is an iPhone 6 [2] it can’t upgrade to iOS 13 and is no longer useful for the book project. So I decided to try to remove it.
That’s where my next set of problems began. I’d make the mistake of creating the book account with an “age” less than 13. Ages are important in Apple’s Screen Time world. Basically:
Age 18 or more: independence, controls stop working, can purchase ad lib, can be Organizer. (Basically at age 18 you need to remove children from Family.)
Age 13: non-vulnerable status but subject to controls, cannot be Organizer. Age 13-18 is the range for Screen Time and content sharing. If you are the caregiver for a vulnerable adult (ex: cognitive disability) and need Screen Time support you need to periodically adjust their birthdate so they are over 13 and under 18. (We need legislation so Apple supports cognitive disabilities they way they support visual disabilities.)
Age 12 or less: vulnerable status. See below for the special rules.
I’d blundered by creating an iCloud ID for a “child” account with a current age of < 13. These vulnerable user accounts are special:
That last bullet point is important. It’s a bit weird, but Apple documents how to create an Apple ID that doesn’t have a payment method. You can use it to buy free apps and tunes.
You can’t, however, turn that Apple ID into a family organizer:
If you're the family organizer for a Family Sharing group and want to share purchases with your family, you're required to have at least one payment method on file. A payment method is also required to set up accounts for children.
If you have an Apple ID like that, and you try to make it a Family Organizer in macOS Mojave iCloud despite the warning, you’ll get this helpful error message:
“There was an unexpected error”. Yeah, Apple was serious about that “requires a credit card” warning, they just didn’t code the error handler response for those who ignored it. I figured given the kludgy workaround Apple documented that the warning was obsolete. Wrong.
Why does Family Sharing require a payment method? I suspect Apple’s hacked together back ends can’t prevent some purchases even when there’s no payment method — and Apple doesn't want to get stuck with the tab. Another possibility is that it’s needed as part of Organizer identity tracing in case a vulnerable child family member is at risk.
So, what do you do when you have too many kids and you need to dump one that’s under 13?
The only recourse, short of phoning Apple support, is create another full Apple ID (age over 18), make it a Family Organizer, and transfer the sub-13 to that “Organizer”. You need hardware to create a full Apple ID, but if you have a Mac you can do it just by adding a system user. I did that to upgrade a limited Apple ID I’d created long ago to a full Apple ID. I then tried to use this fake parent/Organizer without a payment method, which is how I got the “unexpected error”.
After I added a real payment method and confirmed iTunes could see the account change I tried to again make that Apple ID the Organizer for a new family. This took a while. At first the macOS Mojave iCloud Preference Pane would simply display a blank window. After about five minutes it worked. I presume a back end system got updated.
From there I hopped through the transfer process between the macOS account for my new Organizer Apple ID and my iPhone that currently managed my faux 11yo. Some of the screens i saw are illustrative:
I got an error message during the process saying the request had expired, but it went through anyway. I think I got that errant error message because I backed up a screen to do a screenshot. Yeah, this stuff is fragile.
So it appears for now that I’ve moved my fake 11yo from my true Family to a new fake Family where it will sit for another 2 years. Then it will turn 13 and I can vaporize it (I’ve created a future task :-) and then I can remove the payment method for the fake Organizer.
Once I get my strength up I may try to contact Support about some of the other problems with our Family Screen Time, like that handed down device still stuck to my daughters account (or I can just wait until she’s 18 and exits).
Now I need some Scotch, but it’s still a bit early here ...
- fn-
[1] Extending the existing Family Sharing to enable remote Screen Time management was a fatal error.
[2] The iPhone 6 can’t move beyond iOS 12, but Apple is still supporting iOS 12 on it, and since iOS 12 is superior to 13 in several ways the 6 is arguably now a better phone than the 6s.
See also:
If multiple devices share a Store Apple ID they will show up in Apple ID Devices. They will also show in iTunes (for that Store Apple ID), Apple’s current documentation states iTunes is the only way to see and manage this list. “You can have ten devices (no more than five of them computers) associated with your Apple ID and iTunes at one time."
And you thought iTunes was dead!
You have to remove devices manually from this list after you stop using them. If, like me, you use the same Store Apple ID on family devices it’s easy to hit the limit.
The interesting bit is these two lists are different and they don’t synchronize. They are presumably on two different databases.
The applied.apple.com list is current and shows 8 devices. I think if you sign out of a device you’re not using this list will be updated.
The iTunes managed list is not updated when you sign out of a device. You have to update it manually. I think it still supports iPods. It had one of our devices that was no longer active on it, but it also had an old iPhone 4 we use for music only that runs iOS7 [1]
iPod support explains why the iTunes managed list can’t be automatically updated. I don’t know what happens if you exceed the limit on one list but not the other.
- fn -
[1] The iCloud My Devices display supports “iOS 8, macOS Yosemite … or later …”
One of Apple’s “original sins” is the proliferation of Apple IDs and the inability to merge or manage them. I have four that I know of with cryptic and fungible relationships between Apple ID and product ownership. (The worst bugs in the software world are data model bugs.)
In iOS 12 Family Sharing there’s now a setting for Purchase Sharing with an associated Apple ID. Mine is set to my Apple Store ID which is historically distinct from my iCloud ID (many old timers have this unfixable issue). If you tap on this Apple ID it rings up a dialog that allows this to be changed (there’s a bug here — tapping on it doesn’t always work. I had to leave the screen and return to it to enable tap). When I tapped it switched the default to my iCloud Apple ID.
I believe this is a new control. It will be interesting to see what happens when I migrate other family devices that use this iTunes Store ID for purchasing.
At the moment only one Apple ID can be used, but this UI could support multiple Apple IDs. The screen also displays a payment method that cannot be changed, it’s presumably defined by Apple ID.
This is something to watch.
PS. The ten year history of this mess is one reason I recommend Spotify over Apple Music for families.
See also:
Like many veteran geeks I have a different iCloud ID and Apple store ID. This used to be a supported configuration. In my case it was essential because of some complicated history with Apple’s .mac precursor to MobileMe and iCloud. (In an unrelated matter I have another 3-4 Apple IDs that aren’t connected to anything but, depending on the vagaries of Apple’s hacked together legacy databases, sometimes pickup Apple Store hardware purchases.)
This is what Apple’s support document says now (emphases mine) …
Sign in with your Apple ID - Apple Support
… We recommend that you use the same Apple ID for all Apple services on your device—including the iTunes & App Stores and iCloud …
… If you have multiple Apple IDs, you can’t merge them …
I went looking for this document because I think iBooks.app doesn’t work properly with an iCloud ID that’s different from the Apple Store ID that can be used to purchase iBooks. It looks like this will be a trend.
Note what Apple says here. Your Apple Store ID and iCloud ID should be the same. You also can’t merge them [1]. So you either need to abandon all your Apple Store purchases or your iCloud storage purchase.
Anyone remember when Cook promised to fix Apple’s original sin of botched identity management system? Apparently the problem is harder than building spaceship headquarters.
Apple should bite the bullet and come up with a process to merge Apple IDs. I fear they aren’t going to bother though. I really miss class action lawsuits.
- fn -
[1] There is a possible workaround. You may be able to use your iCloud ID as an Apple Store ID and then make it a family member of the original Apple Store ID. This will run into rules about changing device Store IDs and constraints on family member size as well as issues with the total number of devices that are part of a family (10). It isn’t an official workaround and I suspect it has irreversible problems of its own.
Gmail, and some other systems, support a very old email standard that needs a name. Gmail will treat myname+123@gmail.com as though it were myname@gmail.com. It’s handy for filtering email lists.
I wondered if it could use it with Facebook accounts. As I discuss in my book there are many reasons to have Facebook related email for a vulnerable user go to their parent or “Guide”. Facebook doesn’t allow an email address to be associated with more than one account — maybe the + feature would work …
Except it doesn’t. I tried adding a + variant of my personal email to one of the kids accounts and Facebook told me it was in use.
Bummer. Now you know not to try.
Incidentally, iCloud support up to 3 aliases, so you can do this with an iCloud email alias. Alas, regular Gmail does not support true aliases — only the + suffix trick. Google Apps does support aliases, at least if you own a domain, but that’s strictly a geek or business thing.
I’m not sure what’s more amazing — that this has been broken for five years, or that someone once thought this was a clever idea, or that almost no-one understands what’s wrong…
Warning: iCloud Calendar invitations have unpre... | Apple Support Communities
I suspect few people use iCloud Calendar invitations — or else we'd all know about this. It's not a new behavior, it was first documented in 2011. It's still true.
It's important to know about this.
When you send an event invitation to an email address iCloud will look up the person associated with that email address (possibly using Contacts). If that person has an iCloud email address then the invitation will go to their iCloud calendar. No email will be generated. If they don't actually use that iCloud calendar they will never see the invitation.
If the invited person does not have an iCloud address in contacts then an email will be generated.
So if you invite with a gmail address, and iCloud finds an iCloud address associated with the gmail address Contact (see update for correction), no email will be sent to Google Calendar. Instead an iCloud Calendar event will be created.
There is such a thing as being too clever.
Some details are here: http://apple.stackexchange.com/questions/27449/icloud-calendar-not-sending-invit es/29970
I discovered this while doing research for a book on using smartphones to support independent living for special needs teens and adults. Using my sister’s iCloud calendar I invited myself using my gmail address. I didn’t get an email, and her iCloud account didn’t show a sent message. Google found the 2011 StackExchange comment so I checked my unused iCloud calendar. There was the event, waiting acceptance.
A wonderful example of how being clever can be stupid.
Update 1/22/2016
A family member tells me her iCloud invitations appear to recipients with a name that is only associated with the Apple ID she uses for iTunes purposes — because it’s on her credit card.
This suggests the AppleID lookup is based on the email address associated with one’s Apple ID, not on anything in Contacts.app. I visited the AppleID associated with the iCloud calendar that my test invitation appeared on, and it is associated with two non-Apple email addresses. One of them is the gmail address I used in the test invitation.
Note that many people have multiple Apple IDs. I have four. More, Apple now allows one to have an Apple ID with a non-iCloud email address. Note also that it’s been four years since Cook promised Apple would find a way to merge Apple IDs.
This is my new “Apple FUBAR” example.
Update 11/30/2016
Apple has introduced a new Advanced preference setting to iCloud Calendar (web only) that may have been created to fix this problem. They recommend receiving event invitations by email — “if your primary calendar is not iCloud”. Yes, it’s bizarre that this refers to how an iCloud calendar receives invitations, but I think it turns off Apple’s obscure redirect mechanism.
Update 6/16/2023
I think this is still broken. On reviewing the original Stack Exchange post I saw a reference to a bug with invitations that had locations set. I don't know if that was ever fixed.
I sent a text to #3 and she didn’t get it. When I dug in a bit I discovered her iMessage was working, but it was only using her phone number. iMessages sent to her iCloud address were quietly dying.
When I attempted to authenticate her iMessage I got the same oddly formatted username and password request I saw when #1’s iMessage was recently misbehaving. I also saw that her Keychain wasn’t synchronizing. The latter is often a good sign that “something is not right on Apple’s servers”.
I eventually got things working, but I had to turn off iCloud on her iPhone and her OS X accounts and I had to reset her keychain completely. I never saw any error messages, but Apple’s obsolete (iOS 8?!) support note says (emphases mine) …
If you enter your iCloud Security Code incorrectly too many times - Apple Support
If you enter the wrong iCloud Security Code too many times when using iCloud Keychain, your iCloud Keychain will be disabled on that device, and your keychain in iCloud will be deleted. You might see one of these messages…
The documentation on resetting the Keychain and getting a new iCloud Security Code is also obsolete …
Frequently asked questions about iCloud Keychain - Apple Support
… If you enter your iCloud Security Code incorrectly too many times, you can’t use that iCloud Keychain. You can contact Apple Support, who can help verify your identity so that you can try to enter your iCloud Security Code again. After a number of incorrect attempts, your iCloud Keychain is removed from Apple’s servers, and you’ll need to set up iCloud Keychain again...
… Use these steps if you’re using iOS 7.0.3 or later:..
… If you want keychain data to push to all of your devices, but not to the cloud, turn on iCloud Keychain on each device, but skip the step to create an iCloud Security Code.
iOS 7.0.3 eh?
I suspect her mixed up authentication state was because she never had an iCloud Security Code, but did have Keychain device sync — a probably obsolete configuration that’s described in the obsolete documentation.
I was able to reset her iCloud keychain from Yosemite, then create a new iCloud Keychain with a security code. Then I restored iCloud to the phone. After that I was able to turn on iMessage and FaceTime and they both pulled down the login credentials [1].
- fn -
[1] I think a lot of the weirdness if Apple’s iOS authentication arises because the iPhone is covertly using iCloud Keychain to pass credentials between iCloud setup and iMessage/Facetime setup. So for optimal iMessage credentials configuration you need to first get iCloud keychain working. Which all reminds me of this.
I noticed my daughter was receiving email sent from my iPhone with my email address but the sender name of “Gmail personal”.
It took a while to figure out that this sender name was coming from how I named one of the user accounts for Mail.app … on OS X.
I really don’t understand this, but a Google search somehow sent me to this seemingly unrelated conversation ...
Fortunately, I know better than to ignore the nsAI of our time (non-sentient AI) - so I started poking around the configuration of my “Internet Accounts” (Yosemite, click Details after choose account name) and my OS Mail.app Account settings (which are sort of like the “Internet accounts” and sort of not like them).
There I found some oddball settings for Outgoing Mail Server — on a freshly configured machine (I didn’t migrate from prior machine):
I deleted the odd outgoing mail server .. .and Mail.app stopped sending email.
There’s a problem with Yosemite and multiple Google accounts on one OS X user account. i’m still figuring this out. I suspect the keychain is involved...
Update: It seems to be working at the moment. I had to create a unique SMTP server for each account and entering my Google credentials (2F bypass password for one of ‘em). I don’t think it’s supposed to work this way. I think in theory there’s a typical Apple hack whereby one does Google authentication in OS X System Preferences and OS X is supposed to create keychain entries Mail.app uses. In practice this appears to fail when a user has more than one Google account...
An AskDifferent thread also implications the keychain, and since the keychain is iCloud synced its configuration can poison multiple clients. i suspect Apple (engineer? product?) simply decided to ignore people with multiple Google accounts.
Update 9/26/2015:
In much the same thread I ran into a similar configuration problem on a different Yosemite Mac. This time a correspondent reported Google was warning him my email was suspicious:
I figured that Google was seeing a mismatch between the stated sender domain and the SMTP sending service domain. When I looked in Mail.app account configuration (not to be confused with OS X account configuration) I found this:
I have two Google accounts configured, one a Google Apps account (single factor) and another a Gmail account (2FA). The “Home” (2FA) account was using the SMTP server I’d labeled “Gmail Work”. Wrong one.
I switched the the Gmail Home (my definition) SMTP server, which was setup this way by OS X. NOTE the lack of password. Despite the UI displayed here OS X doesn’t actually use the account password. It does some other form of authentication for this 2FA account, possibly via some OAUTH token magic stored in the OS X keychain (which is synchronized between devices, and since Google looks for matches between device and credentials I suspect that causes issues):
After switching the SMTP service to this one (“Gmail Home”) my next email did not generate a phishing warning.
Every year or so I like to check which of my four known Apple IDs has my many Apple hardware purchases associated with it. Two years ago, for example, they all jumped from one Apple ID to another. I assume Apple has a very broken distributed database system, and they try to associate records based on metadata like phone number, mailing address, email addresses, etc. Move a key around, or change the matching algorithm and purchases hop.
Today I’m pleased to report that they’ve now settled into two accounts. For a while they were all with the Apple ID I use for iTunes purchases (but not for iCloud — due to technical bugs/issues with Apple’s id infrastructure). Before that they were with an old dev account. Today 3 purchases are associated with my iTunes Apple ID, zero with my iCloud Apple ID, and 17 with the old Dev account. There’s no obvious logic for which purchase has gotten which Apple ID. Note that the old dev account is never used for anything; it’s completely inactive.
I guess I better tighten up password security on the dev account. I’ll try associated a phone number with it, that ought to really mess Apple up.
If you want to know when Apple lapsed into incompetence, just track their identity management issues. (Hint: well before Cook took over.)
I like the idea of "two-step verification" for my Apple credentials (aka two factor authentication).
Problem is, I have no faith in Apple's ability to get this right, especially given their many years of unresolved Apple ID problems [1]. In particular I wonder about two things:
- fn -
[1] Examples below. Their Apple ID failures are one example of why I think Apple's mind-boggling successes of the late 00s may have also broken the company. There are so many things small and large that Apple can't seem to manage. I'm hoping Cook is doing recovery work.
I made a rare "Genius" consultation today. The visit confirmed that there's no "safe" Apple-approved way to fix broken glass on an AT&T carrier-unlocked iPhone [1].
That was bad, but along the way we tried checking the devices associated with my Apple ID. That would include several iPhones, iMac i5 27", MacBook Air, iPad, iPods, etc, etc.
Except there were NO devices associated with my Apple ID. All of my registration information was gone. Vanished.
Fortunately the 400+ iTunes purchases associated with that Apple ID appear to be intact [3]. So what happened?
I contacted Apple support who, of course, had no idea what had happened. (I'm sure they thought I was merely senile, but the rep was very polite.) However Apple support's reverse number lookup on the phone I was using brought another of my unwanted four Apple IDs. That AppleID had "lots and lots of purchases".
Except I've never used that Apple ID when doing any kind of purchase or authorization. I always use the (.mac) Apple ID associated with my iTunes account. In fact, I only discovered that AppleID existed about 2 months ago!
So I checked what devices were associated with each of my Apple IDs. I went to Contact Apple Support and chose the Your Products option. This is what I found:
So everything was now under a single AppleID, but it was an oddball AppleID that I've never used anywhere. How the heck did that happen? Why choose that AppleID rather than a complete strangers?
I don't know of course, but the most likely explanation is that the Apple's IT systems are kludged together.
I'm guessing that Apple had one IT systems that was used by iTunes and that an older system used for product registration. At some point in the past the "product registration system's" true "Key" was either a phone number or (more likely) an email address. Recently Apple lashed together the two systems, perhaps attempting to "join" on the email address.
That's where my May 2012 MobileMe/AppleID bug came in
... I've figured out the bug. It arose as a side-effect of changes to the way Apple IDs work, and it only impacts people who are still on MobileMe accounts and who have the same email address associated with two Apple accounts prior to the time Apple made that illegal...
I won't repeat the details of the bug here, but the workaround was to remove an authenticated email address from my primary AppleID and associate it with ... yes... that oddball developer account AppleID.
I bet, in database terms, that email address was the "Foreign Key" that linked my iTunes controlled AppleID with my Mac purchase records. Moving the email address from one AppleID to another causes the database query to associate purchases with the AppleID I'd moved it to [2].
I could try moving the email BACK to my primary AppleID, but I'm afraid I'd lose my purchase associations altogether.
[1] Apple's only approved fix is a refurb substitution. Unfortunately, Apple will replace an AT&T-unlocked iPhone with a locked iPhone, the Apple product database doesn't correctly track AT&T changes to a phone's lock status. After replacement the IMEI does not match AT&T records, so the new phone cannot be unlocked.
[2] Reading my blog post from May I even noticed the problem then, but I was too tired to f/u on it: "Apple's Support Profile is supposed to show the products associated with my Apple ID. I think it used to. I don't see them any more. It says my home number is associated with a different Apple ID..." So maybe my home number was also associated with the moved email.
[3] Apple's iTunes group manages AppleIDs, not the Mac group.
