Description of problem:
When machine is joined to AD domain using realm join, it is not possible to use ssh's GSSAPIAuthentication because the auth_to_local, or better yet localauth_plugin is not configured.
realm join should do what ipa-client-install does, add
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Have AD server, assume realm ADDOMAIN.TEST.
2. Have RHEL 7.1 machine.
3. Configure resolv.conf to point to the AD server, or otherwise make sure realm discover finds the AD domain.
4. Run realm join -v ADDOMAIN.TEST
5. Run kinit administrator
6. Run ssh -l administrator@ADDOMAIN.TEST -o GSSAPIAuthentication=yes $( hostname -f )
Creating home directory for administrator@ADDOMAIN.TEST.
to krb5.conf helps, and since that's what ipa-client-install does, realm join should likely do that as well.
Shouldn't there be a standard include directory that is preconfigured with the kerberos packages, where both sssd and other implementations can place config snippets?
Why do we have to modify this during joining a domain?
(In reply to Stef Walter from comment #3)
> Shouldn't there be a standard include directory that is preconfigured with
> the kerberos packages, where both sssd and other implementations can place
> config snippets?
This effort is being tracked in bug 1146945.
> Why do we have to modify this during joining a domain?
I guess because it's currently the best approach we have. Without that includedir, users will have to do the change manually, and we should make it as seamless as possible for them.
Is there development work being done here? Are you interested in contributing a patch toward this?
In my opinion a fix here would be a hack, rather than the real fix in distributing an intelligent krb5.conf by default. But I'm willing to merge a sane patch that implements the hack, until such a time as krb5.conf does the right thing.
Hmm, since realmd does not seem to touch krb5.conf at all and the modification of that file seems to be done by /usr/sbin/authconfig, maybe the correct component to put that includedir to /etc/kr5b.conf is authconfig, after all?
It could be.
But i still think the real solution is to have the includedir in krb5.conf by default.
Closing this bug. Two other solutions:
* authconfig includes this in krb5.conf, since it already configures krb5.conf
* We include a standard include directory by default in krb5.conf (my preference)
So at the end of the day, this wouldn't be implemented in realmd, closing.
(In reply to Stef Walter from comment #10)
> Closing this bug. Two other solutions:
> * authconfig includes this in krb5.conf, since it already configures
Did you clone this bugzilla for authconfig? Or how do we track it for consideration in authconfig? Shouldn't we just flip the component of this bugzilla instead of WONTFIX?
Sure. Please go ahead.
Moving to component.
(In reply to Jan Pazdziora from comment #14)
> Moving to component.
> We'd like
Hit Enter too soon.
Moving to authconfig.
When realm join is used to join host to AD, it calls authconfig to configure krb5.conf. While doing that, it'd be good if authconfig could also put includedir /var/lib/sss/pubconf/krb5.include.d/ there, if sssd is also enabled.
Similar Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1145808
The patch I've written makes authconfig to add the includedir line in case the /var/lib/sss/pubconf/krb5.include.d/ is present and readable. It is a RHEL-7 only hack.
I'm reassinging to realmd as I do not see a way how to fix this in authconfig in this case.
We are still keeping the patch that adds the include in case authconfig needs to update krb5.conf.
Tomas, to me this ticket looks like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1300447. Can you confirm this and close this ticket?
I suppose fixing bug 1300447 should fix this as well however we should independently verify it to be sure.
*** Bug 1299059 has been marked as a duplicate of this bug. ***
My understanding of this bug is that this was an attempt to get Jan's use case work until bug 1146945 (dropping configuration snippets in krb5) makes it's way into RHEL. This seems to happen soon, so I do not see any reason to keep this open.
(In reply to Patrik Kis from comment #30)
> My understanding of this bug is that this was an attempt to get Jan's use
> case work until bug 1146945 (dropping configuration snippets in krb5) makes
> it's way into RHEL. This seems to happen soon, so I do not see any reason to
> keep this open.
> Any objection?
Robbie, will we get functional equivalency of this bugzilla with bug 1146945?
It seems that having snippet directories supported by Kerberos libraries does not necessarily mean that the correct snippets will be put to correct directories.
I do not care as I said fixing bug 1300447 should make it fixed anyway.
If I understand correctly - yes, there will be a place on the system preconfigured to drop snippets so there will not be a need to modify krb5.conf anymore.
(In reply to Robbie Harwood from comment #34)
> If I understand correctly - yes, there will be a place on the system
> preconfigured to drop snippets so there will not be a need to modify
> krb5.conf anymore.
There will be place to drop snippets but will the snippets be there by default?
In other words, will the use case from comment 0 work out of box (even after upgrades from older RHEL 7.x) or will authconfig still need to do something, except instead of putting things to /etc/krb5.conf we'd now need it to drop some snippet somewhere to enable SSSD?
(In reply to Jan Pazdziora from comment #35)
> (In reply to Robbie Harwood from comment #34)
> > If I understand correctly - yes, there will be a place on the system
> > preconfigured to drop snippets so there will not be a need to modify
> > krb5.conf anymore.
> There will be place to drop snippets but will the snippets be there by
> In other words, will the use case from comment 0 work out of box (even after
> upgrades from older RHEL 7.x) or will authconfig still need to do something,
> except instead of putting things to /etc/krb5.conf we'd now need it to drop
> some snippet somewhere to enable SSSD?
The expected use case is that files will either be placed or linked into /etc/krb5.conf.d/ as a single place for this kind of file. Now, dropping files there means they'll be enabled, and I haven't looked at what's being dropped there by authconfig to know if they can be enabled on package install or not, but that's the idea.
I suggest to turn this bug to a TestOnly as actually nothing is going to be fixed under this particular report. Once all pieces are fixed in RHEL-7.3, we can try your scenario and see it works or not and possibly file the needed bugs.
*** Bug 1371814 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.