Hello,
We have a linux machine with a hostname that is longer than 19 characters. AFAIK the SamAccountName attribute in AD is limited to at most 20 characters (inkl. trailing $). I.e. the usable characters is at most 19.
In many AD docs it is stated that a Windows hostname should not exceed 15 characters for backward compatibility, but we do not really care about that.
Could you comment on how does SSSD pick the principal / username name to use for kerberos / ldap authentication / reading the keytab / and so on in the case of the hostname being longer than 19 characters?
I could not find anything in the docs of sssd-ad about this.
Will it use 1) UNRESTRICTED_VERY_LONG_HOSTNAME$ 2) 19_CHARACTERS_HOSTNAME$ 3) 15_CHAR_HOSTNAME$ ?
Thanks for clarifying. It will help us deciding on how to proceed with hosts with long host names.
Best regards, J Brauchle
On Thu, 20 Nov 2014, Joschi Brauchle wrote:
Will it use
- UNRESTRICTED_VERY_LONG_HOSTNAME$
- 19_CHARACTERS_HOSTNAME$
- 15_CHAR_HOSTNAME$
?
Thanks for clarifying. It will help us deciding on how to proceed with hosts with long host names.
I'll leave it to someone who knows to answer the direct question, but you can obviously just tell sssd to use a specific entry if how it behaves doesn't suit how you want. Assuming a suitable cms, that's no effort and works just fine.
jh
I'll leave it to someone who knows to answer the direct question, but you can obviously just tell sssd to use a specific entry if how it behaves doesn't suit how you want. Assuming a suitable cms, that's no effort and works just fine.
jh
Yes, you are right, that is a solution.
The reason I am asking is because we will be setting up tons of linux hosts with a common SSSD config and thus would like to eliminate special configs for individual hosts.
Thus, instead of telling SSSD what to do (which would be a special config for the affected host), we would like to know what SSSD will do and adapt the creation of machine accounts to SSSD. This way, we hope to solve the "long-hostname-problem" on the server side rather than the client side.
J Brauchle
On Thu, 20 Nov 2014, Joschi Brauchle wrote:
Yes, you are right, that is a solution.
The reason I am asking is because we will be setting up tons of linux hosts with a common SSSD config and thus would like to eliminate special configs for individual hosts.
Thus, instead of telling SSSD what to do (which would be a special config for the affected host), we would like to know what SSSD will do and adapt the creation of machine accounts to SSSD. This way, we hope to solve the "long-hostname-problem" on the server side rather than the client side.
I wasn't even meaning it would be a special config. You make a machine with a long name, and you see what gets created in the keytab. Either SSSD works with it, or it doesn't. If it doesn't, it needs fixing in SSSD.
The workaround would be to apply a config across all machines that matches behaviour. Your CMS should let you make that config template be standard everywhere.
jh
On Thu, Nov 20, 2014 at 05:24:24PM +0000, John Hodrien wrote:
On Thu, 20 Nov 2014, Joschi Brauchle wrote:
Yes, you are right, that is a solution.
The reason I am asking is because we will be setting up tons of linux hosts with a common SSSD config and thus would like to eliminate special configs for individual hosts.
Thus, instead of telling SSSD what to do (which would be a special config for the affected host), we would like to know what SSSD will do and adapt the creation of machine accounts to SSSD. This way, we hope to solve the "long-hostname-problem" on the server side rather than the client side.
I wasn't even meaning it would be a special config. You make a machine with a long name, and you see what gets created in the keytab. Either SSSD works with it, or it doesn't. If it doesn't, it needs fixing in SSSD.
I think this is a good point. SSSD should just work.
I did a bit more research and it seems that both Windows clients and realmd truncate the name. Then I think it would be a good idea to let SSSD also search for: SHORTNAME_UP_TO_15_CHARS$@REALM instead of: ANYTHING_UP_TO_THE_FIRST_DOT$@REALM
You have to be careful if you use as me, SSSD and NFS4+krb ; NFS doesn’t agree on connection with sec=krb5 if hostname doesn't match the hostname in keytab file.
Best, Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 22. november 2014 14:48 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] SSSD-AD: SamAccountName 20 character limit - What does SSSD do with longer host names?
On Thu, Nov 20, 2014 at 05:24:24PM +0000, John Hodrien wrote:
On Thu, 20 Nov 2014, Joschi Brauchle wrote:
Yes, you are right, that is a solution.
The reason I am asking is because we will be setting up tons of linux hosts with a common SSSD config and thus would like to eliminate special configs for individual hosts.
Thus, instead of telling SSSD what to do (which would be a special config for the affected host), we would like to know what SSSD will do and adapt the creation of machine accounts to SSSD. This way, we hope to solve the "long-hostname-problem" on the server side rather than the client side.
I wasn't even meaning it would be a special config. You make a machine with a long name, and you see what gets created in the keytab. Either SSSD works with it, or it doesn't. If it doesn't, it needs fixing in SSSD.
I think this is a good point. SSSD should just work.
I did a bit more research and it seems that both Windows clients and realmd truncate the name. Then I think it would be a good idea to let SSSD also search for: SHORTNAME_UP_TO_15_CHARS$@REALM instead of: ANYTHING_UP_TO_THE_FIRST_DOT$@REALM _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, 26 Nov 2014, Longina Przybyszewska wrote:
You have to be careful if you use as me, SSSD and NFS4+krb ; NFS doesn’t agree on connection with sec=krb5 if hostname doesn't match the hostname in keytab file.
There's nothing stopping you having RABBITS$@DOMAIN and nfs/fqdn@DOMAIN and NFS should be perfectly happy. Having correctly defined fqdn princs is obviously rather important to lots of services.
jh
On 26/11/14 09:54, John Hodrien wrote:
On Wed, 26 Nov 2014, Longina Przybyszewska wrote:
You have to be careful if you use as me, SSSD and NFS4+krb ; NFS doesn’t agree on connection with sec=krb5 if hostname doesn't match the hostname in keytab file.
There's nothing stopping you having RABBITS$@DOMAIN and nfs/fqdn@DOMAIN and NFS should be perfectly happy. Having correctly defined fqdn princs is obviously rather important to lots of services.
jh
Hi Simplifying further, only the nfs server needs the nfs/ principal. Clients are happy with MACHINE$ or host/, which you usually have anyway. HTH, Steve
Sure. Nfs server needs nfs/ SPN; I experienced problem on client with SHORTNAME$@ and host/fqdn@ and Hostname=fqdn; this combination made NFS server completely daef until client got FQDN$@ principal.
Best Longina
Den 26/11/2014 kl. 20.50 skrev steve steve@steve-ss.com:
On 26/11/14 09:54, John Hodrien wrote:
On Wed, 26 Nov 2014, Longina Przybyszewska wrote:
You have to be careful if you use as me, SSSD and NFS4+krb ; NFS doesn’t agree on connection with sec=krb5 if hostname doesn't match the hostname in keytab file.
There's nothing stopping you having RABBITS$@DOMAIN and nfs/fqdn@DOMAIN and NFS should be perfectly happy. Having correctly defined fqdn princs is obviously rather important to lots of services.
jh
Hi Simplifying further, only the nfs server needs the nfs/ principal. Clients are happy with MACHINE$ or host/, which you usually have anyway. HTH, Steve
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 26/11/14 21:09, Longina Przybyszewska wrote:
Sure. Nfs server needs nfs/ SPN; I experienced problem on client with SHORTNAME$@ and host/fqdn@ and Hostname=fqdn; this combination made NFS server completely daef until client got FQDN$@ principal.
Hi It works for us and is confirmed by the man page: http://linux.die.net/man/8/rpc.gssd
Maybe if it's not working for you, then file a bugzilla against your distro?
Not sure whether you are asking for help or just reporting a problem as a warning for others. If the latter, maybe post your distro too.
Cheers, Steve
Hi Steve, This is Ubuntu TRusty LTS, with nfs-utils-1.2.8 version. I finally get it working .
Rpc.gssd looks up for HOSTNAME$@ principal for whatever it finds in /etc/hostname;
If I used short name in /etc/hostname, it broke dyndns in SSSD ( in my case nsupdate send record with "shortname." - didn't work.
SHORTNAME$@ principal with fqdn in /etc/hostname and UPN=host/fqdn@ didn't work as well.
I am actually waiting for SSSD updates in my distro - we have still 1.11.5;
Mange hilsner Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@lists.fedorahosted.org] On Behalf Of steve Sent: 26. november 2014 21:45 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] SSSD-AD: SamAccountName 20 character limit - What does SSSD do with longer host names?
On 26/11/14 21:09, Longina Przybyszewska wrote:
Sure. Nfs server needs nfs/ SPN; I experienced problem on client with SHORTNAME$@ and host/fqdn@ and Hostname=fqdn; this combination made NFS server completely daef until
client got FQDN$@ principal.
Hi It works for us and is confirmed by the man page: http://linux.die.net/man/8/rpc.gssd
Maybe if it's not working for you, then file a bugzilla against your distro?
Not sure whether you are asking for help or just reporting a problem as a warning for others. If the latter, maybe post your distro too.
Cheers, Steve
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, 27 Nov 2014, Longina Przybyszewska wrote:
Hi Steve, This is Ubuntu TRusty LTS, with nfs-utils-1.2.8 version. I finally get it working .
Rpc.gssd looks up for HOSTNAME$@ principal for whatever it finds in /etc/hostname;
If I used short name in /etc/hostname, it broke dyndns in SSSD ( in my case nsupdate send record with "shortname." - didn't work.
SHORTNAME$@ principal with fqdn in /etc/hostname and UPN=host/fqdn@ didn't work as well.
I am actually waiting for SSSD updates in my distro - we have still 1.11.5;
Entirely down to your distro and the nfs-utils package AFAIK. Setting it up with a UPN nfs/fqdn@ princ is probably the one that'll work in more cases than any other.
jh
On Thu, 27 Nov 2014 10:46:44 +0000 Longina Przybyszewska longina@sdu.dk wrote:
Hi Steve, This is Ubuntu TRusty LTS, with nfs-utils-1.2.8 version. I finally get it working .
Rpc.gssd looks up for HOSTNAME$@ principal for whatever it finds in /etc/hostname;
This has been fixed in march: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=5be4b2d7786d3eae...
Maybe ask Ubuntu to backport this fix ?
Simo.
If I used short name in /etc/hostname, it broke dyndns in SSSD ( in my case nsupdate send record with "shortname." - didn't work.
SHORTNAME$@ principal with fqdn in /etc/hostname and UPN=host/fqdn@ didn't work as well. I am actually waiting for SSSD updates in my distro - we have still 1.11.5;
Mange hilsner Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@lists.fedorahosted.org] On Behalf Of steve Sent: 26. november 2014 21:45 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] SSSD-AD: SamAccountName 20 character limit - What does SSSD do with longer host names?
On 26/11/14 21:09, Longina Przybyszewska wrote:
Sure. Nfs server needs nfs/ SPN; I experienced problem on client with SHORTNAME$@ and host/fqdn@ and Hostname=fqdn; this combination made NFS server completely daef until
client got FQDN$@ principal.
Hi It works for us and is confirmed by the man page: http://linux.die.net/man/8/rpc.gssd
Maybe if it's not working for you, then file a bugzilla against your distro?
Not sure whether you are asking for help or just reporting a problem as a warning for others. If the latter, maybe post your distro too.
Cheers, Steve
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Nov 20, 2014 at 06:09:42PM +0100, Joschi Brauchle wrote:
Hello,
We have a linux machine with a hostname that is longer than 19 characters. AFAIK the SamAccountName attribute in AD is limited to at most 20 characters (inkl. trailing $). I.e. the usable characters is at most 19.
In many AD docs it is stated that a Windows hostname should not exceed 15 characters for backward compatibility, but we do not really care about that.
Could you comment on how does SSSD pick the principal / username name to use for kerberos / ldap authentication / reading the keytab / and so on in the case of the hostname being longer than 19 characters?
I could not find anything in the docs of sssd-ad about this.
Will it use
- UNRESTRICTED_VERY_LONG_HOSTNAME$
This one. In general, SSSD matches principals in this order: hostname@REALM SHORT_HOSTNAME$@REALM host/hostname@REALM *$@REALM host/*@REALM host/*@*
If none of the above match, we pick the first principal. The asterisk acts a wildcard.
- 19_CHARACTERS_HOSTNAME$
- 15_CHAR_HOSTNAME$
?
Thanks for clarifying. It will help us deciding on how to proceed with hosts with long host names.
The safest approach is to manually set ldap_sasl_authid to the right principal.
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
John Hodrien -
Joschi Brauchle -
Longina Przybyszewska -
Simo Sorce -
steve