Bug 970266

(In reply to Ted W. from comment #0)
> Description of problem:
> When selecting "Use Enterprise Login", user can not enter information in the
> "Domain" field.
> 
> Version-Release number of selected component (if applicable):
> Unknown
> 
> How reproducible:
> Consistent
> 
> Steps to Reproduce:
> 1. Install Fedora 19 Beta
> 2. During installation, do not select to create a user
> 3. Reboot system when installation completes
> 4. Proceed to create first user and select "Use Enterprise Login"
> 5. Try to click on the "Domain" field and enter text
> 
> Actual results:
> Unable to enter text in this field and though the field appears to be
> capable of being a drop down style menu, no drop down menu appears.
> 
> Expected results:
> Field should either allow user input or drop down menu should activate with
> user interaction.

Will try to duplicate this bug.

> Additional info:
> With the old anaconda installer, the user used to be able to specify
> information about an LDAP server. I was expecting this screen to behave in a
> similar fashion but it instead appears to want to connect me to an Active
> Directory server. In our environment, we have an active directory server but
> we do not connect our Fedora machines to this server but instead use a 389
> ldap server. As of this Fedora 19 Beta release, I'm unable to proceed with
> our installations as we would normally since we neither connect to an Active
> Directory Server nor utilize local user accounts.

While there are plans to add some standardized best-practice LDAP support to realmd, authconfig (or authconfig-gtk) continues to be available to complete such legacy custom LDAP configurations.

I'm able to type into gnome-initial-setup.

Could you provide more information about how you cannot provide user input to the domain field in gnome-initial-setup? Could you provide a screenshot (if this is a virtual machine) or a picture? Can you type into the other fields?

Jasper, is there somewhere we can see the gnome-initial-setup terminal output, to see if some precondition is failing?

I tried to reproduce my own steps again within a kvm VM using virt-manager. I am now able to type in the name of a "domain or realm".

This brings up another issue, however. Our organization uses an ldap server with no bind username and password. I am unable to type in the name of the ldap server and proceed without entering a username and password. It appears as though the installer is now making the assumption that you would always need credentials for binding to the login server. Under a windows domain controller this would be true but we are using a 389 ldap server and do not require authentication for a machine to use it for user login.

(In reply to Ted W. from comment #3)
> I tried to reproduce my own steps again within a kvm VM using virt-manager.
> I am now able to type in the name of a "domain or realm".

Okay. good to know.

realmd (which provides the underlying support for this page of the gnome-initial-setup GUI) doesn't yet support using legacy LDAP servers directly. This is something we need to implement: https://bugs.freedesktop.org/show_bug.cgi?id=66957

Obviously a better, best-practice, and secure alternative is to use FreeIPA. 

> This brings up another issue, however. Our organization uses an ldap server
> with no bind username and password. I am unable to type in the name of the
> ldap server and proceed without entering a username and password. It appears
> as though the installer is now making the assumption that you would always
> need credentials for binding to the login server. Under a windows domain
> controller this would be true but we are using a 389 ldap server and do not
> require authentication for a machine to use it for user login.

I believe gnome-initial-setup is expecting you to enter the user name and password for the first user account that will use the computer, it's not asking for a domain administrator password (if necessary for configuration that would have come in a popup prompt).

However note that even if you did this, for your setup it wouldn't work due to missing support for using legacy LDAP servers directly.

The current gnome-initial-setup interface does not handle the use case for setting up a workstation with multiple users logging in. I believe this is a well known issue by the gnome-initial-setup developers (I'm just a contributor), but I don't think it's resolved where this functionality should go.

Since we're tracking the legacy LDAP issue elsewhere, I'll leave this bug open for the gnome-initial-setup maintainers to handle appropriately.

Stef, can you provide me an example of how I would configure this for Active Directory then or whatever mechanism it does current support? I ask because I've tried connecting it to both our Active Directory server as well as our LDAP server now using my user credentials (not the admin credentials as I mentioned previously) and neither of them seem to work and all I am presented with is a triangular warning icon with an exclamation mark inside of it which tells me next to nothing about why it won't connect. I'm currently typing in a typical LDAP URI for both server settings, it looks similar to the following examples:

ldaps://exchange-server.example.com:3289

ldaps://ldap-server.example.com

Just do what it says and type your Active Directory domain name like 'example.com'. in the box. As with a normal client (like Windows) the domain needs to be resolveable using DNS.

You should also be able to specify a server name, (no URL format), although this is an advanced feature.

If you go to a console you can type the following to see details of the realm resolution:

# realm discover --verbose example.com

or 

# realm discover --verbose exchange-server.example.com

The lack of function with an LDAP/Kerberos setup is a significant regression from previous Fedora releases.  Previously, one had only to switch to another terminal and install a host key before proceeding.  Now, one cannot proceed at all (without creating a local user account; see bug 1003860) because gnome-initial-setup will not allow the user to proceed without either a local user account or a successful "enterprise" login.

Still a problem in Fedora 20.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Testing this in Fedora 22. The issue seems at least partially resolved. I was able to join a test VM to Active Directory in much the same fashion as one would join a Windows system to Active Directory (entering in the domain and user followed by a Domain Admin user and password to join the system to the domain). We have done away with legacy LDAP internally in favor of FreeIPA, however, so I am unable to test whether legacy LDAP integration problems still persist.

I will see if I can get a basic legacy LDAP server up and running and test against that soon but if someone else has one still in production and could test joining it from the first run utility that would helpful.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.