Proposing as a final blocker:

https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#Expected_installed_system_boot_behavior

"A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account."

OK, we (still) need to tweak that criterion, but basically, we require that account creation works at some point before you get to the login screen. This is effectively broken for the KDE path (GNOME path is complicated as g-i-s gives us a second bite at the cherry; KDE path is clearer since it uses anaconda then initial-setup) with any non-local user account at present. It's arguable whether that's a wide enough impact to block release for, but we should at least discuss it. And it should clearly be an FE bug, IMHO.

Discussed at 2013-06-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-03/f19final-blocker-review-2.2013-06-03-16.00.log.txt . This is definitely accepted as a freeze exception issue, but we did not feel that we had the necessary experience at the meeting to make a call as to whether remote auth config ought to be release critical or not - we just don't know how important it is to those who use remote auth that it be configurable interactively before first login (or whether they'd be fine with creating a local account first and then configuring remote auth from there). Please, if you have input on whether this should be a blocker issue, post a comment.

Discussed at 2013-06-05 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-05/f19final-blocker-review-3.2013-06-05-16.05.log.txt .  Based on the feedback received on devel@ so far we're rejecting this as a blocker: overall the impression we're getting is that people who use remote auth already didn't find firstboot reliable for it and are already used to working around getting it set up outside of anaconda/'firstboot' stages.

We are accepted the bug as a freeze exception issue, though. Obviously if this can be 'fixed' - as in, useful remote auth code put in in time for Final - that would be good. The other option, if there's no chance of any usable remote auth setup code going in before Final, would be to suppress the button so it doesn't confuse/disappoint people.

May as well just remove it for now.

anaconda-19.30.3-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/anaconda-19.30.3-1.fc19

Package anaconda-19.30.3-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-19.30.3-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10283/anaconda-19.30.3-1.fc19
then log in and leave karma (feedback).

For release notes: we should note that there's no remote auth configuration in the anaconda/i-s path and only FreeIPA and AD support in the anaconda/g-i-s path; all other cases require kickstart (in %post, I guess) or post-install configuration.

I've added a Release Note for this. Thanks for flagging, Adam!

anaconda-19.30.3-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.