Bug 984201 - [RFE] When joining AD domain with RFC2307 attributes auto set sssd to use them
[RFE] When joining AD domain with RFC2307 attributes auto set sssd to use them
Status: CLOSED DUPLICATE of bug 906951
Product: Fedora
Classification: Fedora
Component: realmd (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stef Walter
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-13 10:37 EDT by Colin.Simpson
Modified: 2013-07-25 07:41 EDT (History)
6 users (show)

See Also:
Fixed In Version: ssorce@redhat.com
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-25 07:41:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Colin.Simpson 2013-07-13 10:37:23 EDT
Description of problem:

When joining an AD domain with RFC2307 attributes present should realmd automatically set "ldap_id_mapping = False" or at least provide a flag to do this on the realm join so making setup more trivial for domains with Unix attributes present in AD.

Also I wonder whether "use_fully_qualified_names" should be False by default (or again an option flag). I realise making this True is the safe option, but they are ugly and hopefully most forest's are sensible enough to use unique usernames cross domain. I know this is a tricky one and I'm maybe arguing for my own convenience vs what's the sensible thing in the real world.

One more thing, I always wonder whether an AD join should try and autoset "delegation" on computer objects to allow SSH credential forwarding. I've not seen any AD connector software do this by default on a join and you can probably set the computer container to do this automatically, but any thoughts?
Comment 1 Stef Walter 2013-07-15 07:35:07 EDT
(In reply to Colin Simpson from comment #0)
> Description of problem:
> 
> When joining an AD domain with RFC2307 attributes present should realmd
> automatically set "ldap_id_mapping = False" or at least provide a flag to do
> this on the realm join so making setup more trivial for domains with Unix
> attributes present in AD.

As far as I am aware, there is no way to know whether the attributes are in use and maintained correctly for users/groups/computers. It seems impossible to auto-detect this. Although if you have a foolproof (or mostly foolproof method) I'd be interested in hearing about it.

Obviously, the default can be changed for systems you build/deploy using: http://www.freedesktop.org/software/realmd/docs/realmd-conf.html

> Also I wonder whether "use_fully_qualified_names" should be False by default
> (or again an option flag). I realise making this True is the safe option,
> but they are ugly and hopefully most forest's are sensible enough to use
> unique usernames cross domain. I know this is a tricky one and I'm maybe
> arguing for my own convenience vs what's the sensible thing in the real
> world.

Yeah, again this is hard to detect properly. Keep in mind that the users may also conflict with local accounts. So I agree that it's hard to make this a default for everyone.

> One more thing, I always wonder whether an AD join should try and autoset
> "delegation" on computer objects to allow SSH credential forwarding. I've
> not seen any AD connector software do this by default on a join and you can
> probably set the computer container to do this automatically, but any
> thoughts?

Sounds interesting. Do you really use computer account credentials when connecting via SSH + GSSAPI?
Comment 2 Colin.Simpson 2013-07-15 16:21:42 EDT
You are right (I believe) that any detection of correct RFC2307 attributes will come down to heuristics at best, do the UIDs, GIDs, Shell etc look sensible etc When I think of it, a correctly setup GECOS would maybe be the best guide i.e containing the users full name, but again just a guess I guess this default comes down to where you find the current state of AD deployments out there, populated RFC2307 or not. You guys will know best. Personally I think encouraging people to RFC2307 is likely to provide better cross environment interoperability. This will include things like different Linux/Unix AD connector technologies (commercial ones too) and even things like the Windows Server NFS. Mapping seems easy initially but in the long term seems so much less manageable, in an enterprise sense with a large Linux estate.

On the "delegation" issue, yes you need to use the computer account to obtain the the host/hostname service ticket when you SSH. Delegation is required to have a TGT on your destination when you have SSH'd in (passwordless GSSAPI) from Windows. I seem to remember Linux machines don't need this. But definitely required if putty'ing GSSAPI (and essential for this if you have an NFSv4 homedir). A quick google on this give a Centrify result:

http://community.centrify.com/t5/Centrify-enabled-OpenSSH-PuTTy/Centrify-putty-ticket-not-forwarded/td-p/4908

Maybe again an option, as you are loosening a security restriction slightly.

Thanks
Comment 3 Stef Walter 2013-07-22 09:55:32 EDT
Previous request for the same thing: bug #906951
Comment 4 Stef Walter 2013-07-24 12:25:08 EDT
(In reply to Colin Simpson from comment #2)
> On the "delegation" issue, yes you need to use the computer account to
> obtain the the host/hostname service ticket when you SSH. Delegation is
> required to have a TGT on your destination when you have SSH'd in
> (passwordless GSSAPI) from Windows. I seem to remember Linux machines don't
> need this. But definitely required if putty'ing GSSAPI (and essential for
> this if you have an NFSv4 homedir). A quick google on this give a Centrify
> result:
> 
> http://community.centrify.com/t5/Centrify-enabled-OpenSSH-PuTTy/Centrify-
> putty-ticket-not-forwarded/td-p/4908

Simo, do you have any comments on what a good course of action is here, and what sensible delegation defaults are?

My gut reaction would be that Windows admins would be uncomfortable with us turning on delegation for the computer account by default.
Comment 5 Simo Sorce 2013-07-24 13:31:07 EDT
(In reply to Stef Walter from comment #4)
> (In reply to Colin Simpson from comment #2)
> > On the "delegation" issue, yes you need to use the computer account to
> > obtain the the host/hostname service ticket when you SSH. Delegation is
> > required to have a TGT on your destination when you have SSH'd in
> > (passwordless GSSAPI) from Windows. I seem to remember Linux machines don't
> > need this. But definitely required if putty'ing GSSAPI (and essential for
> > this if you have an NFSv4 homedir). A quick google on this give a Centrify
> > result:
> > 
> > http://community.centrify.com/t5/Centrify-enabled-OpenSSH-PuTTy/Centrify-
> > putty-ticket-not-forwarded/td-p/4908
> 
> Simo, do you have any comments on what a good course of action is here, and
> what sensible delegation defaults are?
> 
> My gut reaction would be that Windows admins would be uncomfortable with us
> turning on delegation for the computer account by default.

You should not do this by default, it has important security consequences and the admin needs to make a conscious decision.
Having a switch to do it is quite fine though.
Comment 6 Stef Walter 2013-07-25 07:41:37 EDT
Separate enhancement bug for delegation: bug #988349

*** This bug has been marked as a duplicate of bug 906951 ***

Note You need to log in before you can comment on or make changes to this bug.