[SSSD-users] Re: SSSD performance

[John Hodrien]

On Thu, 26 Mar 2020, Jannis Mann wrote:


Hi John,
thanks for your input!

Sorry, I've meant ignore_group_members = true

I already read about the tmpfs idea but I worry a little when the vm fails and 
then one restarts with out a connection to the domain controller the users are 
not able to login anymore...
- at least that is what I am thinking


You lose cached credentials by going that route, but I don't think you're 
likely to see other significant bother.  We've not noticed any issues.

ignore_group_members breaks applications that expect to be able to get a list 
of members of a group, rather than which groups a user is a member of.

jh
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: SSSD performance

[John Hodrien]

On Thu, 26 Mar 2020, Jannis Mann wrote:


Hi,
I just want to check wether the performance of sssd is alright or if there
is room for improvement.

I am using a binding account to query the Active Directory.
I've configured a nesting level of 1.

When I login the first time or run the id command it takes around 5 secs to
finish when the user is member of ~100 (nested) groups in the AD.
It takes around 10 secs if the user is member of ~200 (nested) groups.

So you can say the loading time is increasing linearly to the membership of
groups.

Unfortunately I need to use a nesting level of 1. I've set group members to
false and enumeration off.

Are these values in an acceptable area? What experiences did you make?


ignore_group_members = true

If you're in a situation where you can set this, it makes a massive difference 
to performance (especially where you have large groups).

I've not retested with newer versions of SSSD, but in the past mounting 
/var/lib/sss/db as tmpfs made another big performance difference.

We were getting >60 seconds times for an initial login of a user, which would 
cause timeouts elsewhere.  This ends up bringing it down to more like one second 
for a typical case, and once it's been cached much faster than that.

That was with nesting level 4.

jh___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Change primary group

[John Hodrien]

On Thu, 19 Mar 2020, Sumit Bose wrote:


Hi,

not really.

Since you say the primary group is called 'Domain Users' I assume you
are using AD. With AD SSSD can derived UIDs and GIDs automatically from
the SID of the AD objects with 'ldap_id_mapping = True' (see man
sssd-ldap for details. With this users will get private primary groups
automatically, but all UIDs and GIDs on your systems will change.

The alternative would be to change the primary group for all users in
AD.


I'm not sure having all users with the same primary group is in itself a 
security issue.  They're free to be in secondary groups too, and if you're 
allocating permissions on those secondary groups, all is well.

The only issue would be if you're writing files out and making them group 
accessible without thinking about which group that should be.

jh
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Use the users Kerberos credentials with 'ldap_sasl_mech = gssapi'

[John Hodrien]

On Fri, 6 Dec 2019, Jasper Siepkes wrote:


Hi,

Thanks for the reply and sorry I missed the other question (my Google-foo is 
apparently a bit weak today ;-).


To cut it short, this is not possible because many login programs need to 
information about the user before the password or other credentials

are available.

Would you folks be open to a patch which adds a flag to use the users own 
Kerberos credentials for environments where hosts are less trusted (ie. desktop 
deployments)? The documentation could add a warning that this won't work for 
all deployment scenario's.

I understand this might be a problem for applications like ssh however those 
kind of applications are not part of a normal office desktop deployment I 
think. Those type of applications are usually part of server deployment 
scenarios where the host itself is also more trusted then some desktop sitting 
in an office.


I'd be interested to know how you'd make this work.  A default pam stack would 
keel over if it didn't already know the user information, as it'd typically block 
access to pam_sss if the UID was < 1000.

jh
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Getting cifs.idmap working on Debian

[John Hodrien]

On Tue, 12 Mar 2019, Sumit Bose wrote:


If I understand the "multiuser" option correctly it should be possible
to use Kerberos credentials stored during login if sec=krb5 or sec=krb5i
is used. For NTLM there is pam_cifscreds which can be added to the PAM
configuration. You might have to add the 'forward_pass' to pam_sss.so in
the auth section as well to make sure pam_sss will put the password on
the PAM stack for other modules.


You do indeed understand the option correctly.  We use sec=krb5,multiuser
quite happily that way, getcifsacl returns sensible information, and access is
controlled using per-user krb5 as expected.

jh
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: recreate machine keytab file

[John Hodrien]

On Mon, 9 Jul 2018, Ondrej Valousek wrote:


Thanks,
"net ads keytab create" does work, but it populates my keytab with all
accounts (user and computer) that can be found in AD - i.e. pretty
dangerous.  I would like to add it some parameter to only will with entries
relevant for my computer - i.e. something like:

Net ads keytab create --only-obj 

Which would add UPN and SPN (both can be easily grabbed from AD) related to my 
hostname.


It does *what*?!!!

jh
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/UBGWXKSGSXVD5FYUK7YYHD6BLETMEXVO/

[SSSD-users] Re: Missing keytab == no login ?

[John Hodrien]

On Tue, 24 Apr 2018, Joakim Tjernlund wrote:


Yes, but every now and then joining the domain or loosing the keytab during
computer upgrade happens and then no one can login other than local root and
that is impractical.  Can one combine simple LDAP bind with xxx_provider=ad?


How often are you finding you're losing your keytab?  If you update a machine,
you shouldn't lose your keytab.

If you reinstall a machine, you should either preserve your keytab, or rejoin
the domain as part of the install.

But for an installed system, I think you quickly reach a point where using
krb5 for NFS/Samba or other services becomes highly desirable, and none of
that flies unless you've got a local keytab.

There are other authentication methods you can use to access a machine
remotely other than as root with a password when SSSD is in an unusable state.

Whether it's possible or not, I'd question whether you really want to go down
that road.

jh
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Kerberos Ticket renewal within Samba AD Domain

[John Hodrien]

On Wed, 18 Oct 2017, Michael Löffler wrote:


Dear SSSD Users,

I have a question regarding the renewal of Kerberos tickets within a Samba 
AD. All servers and clients are running Ubuntu 16.04. We have a lot of 
Windows clients too; therefore we're using Samba. First of all, I'll 
summarize our setup:


- One server acts as the Samba AD Host (and Kerberos (integrated in Samba) 
principal)
- One server acts as a file server; all directories (the users' home 
directories as well) are exported via kerberized NFS
- The clients mount the directories; login auth is realized using sssd (with 
id_provider = ad, auth_provider = ad and access_provider = ad)


When a user logs in at a client, he gets a Kerberos ticket and is therefore 
granted access to his home directory. If he locks the screen and logs in 
again, the ticket is renewed. However, if the user keeps the client locked 
for a time greater than the ticket lifetime, the ticket expires and the user 
is not able to write to his home directory any more. That's a problem if the 
user is, for example, running a process which takes a long time (in our case 
mostly simulations which are usually run overnight). The same things happens 
if a user connects to a client via ssh. Then, the ticket is never renewed 
automatically.


I'd like to thin renewal would work with the ssh case, but you'll not get a
new key set.  GSSAPIRenewalForcesRekey can help if you've got a local machine
that is getting used regularly but with remote connections out to other hosts
via ssh.

Is it somehow possible to configure that sssd renews the krb5 ticket if the 
user has active processes running?


I think you need to be clearer about renewing and getting a new ticket.
Kerberos tickets have a renewal lifetime, and SSSD can renew up to that
lifetime.  If you unlock the screensaver, you get a new ticket, not a renewal,
and so the clock starts again.

If SSSD was able to request new certificates for a user, presumably it'd have
to squirrel away a plaintext copy of the user's password, or the machine would
have to granted additional rights to impersonate other users.  Neither of
those sound like particularly healthy options.

jh___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: User Kerberos lifetime ticket.

[John Hodrien]

On Fri, 1 Sep 2017, Michal Židek wrote:


See man sssd-krb5 and option:
krb5_renew_interval

Is this what you are looking for? Look for other options
in that man page too, maybe you will need some of them.


If this is against a typical AD installation, that'll get you automatic
certificate renewals for up to 7 days.

jh___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: 2008AD and uidNumber, gidNumber mapping on CentOS7 with sssd

[John Hodrien]

On Wed, 19 Jul 2017, Jelle de Jong wrote:

The problem is I am at a customer that has an old Windows 2008 AD server with 
Unix tools and the uidNumber, gidNumber, unixHomeDirectory and loginShell 
need to be used, so that my nfs shares have the correct mapping.


That's fine.


[sssd]
services = autofs


Do you really only want autofs?


[autofs]

I have no idea how to get my user authentication working with the correct 
uidNumber, gidNumber mapping.


Can somebody maybe help?


My advice would be:

Stop using the ldap provider.
Use the ad provider, and join your machines to the domain and use GSSAPI auth.
No need to do anything with TLS, auth will just work.

ldap_id_mapping = False

Point it specifically at whatever attributes you need to, e.g.
ldap_user_uid_number = msSFU30UidNumber

jh
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: login hangs with enumerate = true

[John Hodrien]

On Sun, 11 Jun 2017, Jakub Hrozek wrote:


Oh, sure. The other alternative might be to mount the cache to tmpfs.


I'm an advocate of this method.  With older versions of SSSD, against our
relatively large AD, the performance boost from running with tmpfs was
immense.  This advantage has been reducing over time, as a normally configured
SSSD's performance has improved greatly in our configuration.

jh
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: user id getting lost

[John Hodrien]

On Mon, 29 May 2017, Thomas Beaudry wrote:


?Hi Guys,

I am running into a problem recently where my username is getting lost, and
being associated to a number.  I disabled reverse DNS in the past based on a
suggestion from another sssd user, which seemed to work for awhile.


When you say your username is getting lost, what do you mean?  Do you mean
that 'id' doesn't know who you are, or do you mean 'ls -l' is showing files as
being owned by a number not a name.  If it's the latter, is NFS involved?  Is
the number correct?

More info would be useful.

jh
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Shell customization for SSSD users

[John Hodrien]

On Mon, 27 Mar 2017, m...@vitalykarasik.com wrote:


We have a few RHEL7 boxes for developers, users are authenticated with SSSD
against AD.
Each developer has his/her own Linux machine, all Linuxes are managed by
Puppet.  Till now all users used BASH ("default_shell = /bin/bash").  Now we
have a few users which want ZSH. Because we'd like to keep sssd.conf
standard on all linuxes, we  thought about use something like:

allowed_shells = /bin/zsh,/bin/bash
shell_fallback = /bin/bash

So if certain linux box has ZSH installed, user will get it; else it will
use BASH.  We tried this config, and played with other shell-related config
params - nothing work.  Users receive /bin/sh instead of bash and zsh.

Any ideas?


If you want users to get the shell they want, then you need to set the shell
they want in Active Directory, and make sure SSSD is configured to look at the
right attribute.  Otherwise you may find it's reading a duff attribute, or
it's reading the right one but it contains /bin/sh.

If you're managing it by puppet, and you actually want the config you
describe, you could just set default_shell for the machines differently, so
it's set to zsh on some and bash on others.

jh
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Multiple mount autofs/sssd

[John Hodrien]

On Fri, 2 Dec 2016, john lehardos wrote:


Hello,

I am looking for a solution to mount two different NFS exports on a same 
mountpoint in order to have this kind of configuration

server1:/path   on /s/work
server2:/path   on /s/work

/s/work :
  - fileA_server1
  - fileB_server1
  - fileA_server2
  - fileB_server2

The /s/work mountpoint is provided by autofs/sssd and the map is on an LDAP 
autofs OU.

I have tried many solutions, but I want to avoid the symlink to another mounted 
directory solution.
Can anyone help ?


Do you not actually just want /s/work to be a map that includes four
automounts?

jh
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: 'no primary group ID provided' when trying to use ldap mode against AD

[John Hodrien]

On Mon, 29 Aug 2016, Jakub Hrozek wrote:


btw one more remark. Even if you can't join the client to AD and have to
resort to id_provider=ldap there is nothing preventing you from using:
   auth_provider=krb5
at least as long as the KDC is reachable..


Although without a system keytab (typically the machine credential), you can't
validate that you're talking to the correct KDC, can you?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: autofs question

[John Hodrien]

On Fri, 26 Aug 2016, Thomas Beaudry wrote:


Hi guys,

I'm still stuck on this.  I'd be willing to give a $50 gift card to someone
who can help.  I found out that my netapp uses NFSv3.


If it's set to export NFSv3, what happens when you mount it?  Does it mount
sec=sys or sec=krb5?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: autofs question

[John Hodrien]

On Tue, 23 Aug 2016, Thomas Beaudry wrote:


Hi John,

Are you sure i have to configure idmapd?  My NAS has windows samba shares.


If it's CIFS, then you probably want to look at:

man mount.cifs

Particularly:

cifsacl
multiuser

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: autofs question

[John Hodrien]

On Tue, 23 Aug 2016, Thomas Beaudry wrote:


Hi John,

Thanks for answering.

Adding sec=krb5 to my auto.data file automounted the directory.

I noticed that the group and owner of the mounted directory is root.  Would
you know how to get the proper ones (from the NAS itself).


It's all sorted via the idmapper, but I can't speak for how your NAS works.
I'd check the documentation provided from your vendor.

/etc/idmapd.conf

Domain/Local-Realms are the important bits, and they need to suitably match
client and server.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: keyring: disk quota exceeded

[John Hodrien]

On Wed, 27 Jul 2016, Stephen Gallagher wrote:


Is this on a GNOME workstation? We recently discovered a bug in GNOME Online
Accounts that can (in rare circumstances) cause the keyring to fill up with
garbage which ends up preventing the legitimate values from being updated).


Have you got a BZ for this, or more details on what triggers it?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: keyring: disk quota exceeded

[John Hodrien]

On Wed, 27 Jul 2016, Ondrej Valousek wrote:


Hi List,

Or RH-7 box I am getting message like this:

[root@spartacus bin]# kinit
kinit: Disk quota exceeded while getting default ccache

Google gave this: https://bugzilla.redhat.com/show_bug.cgi?id=1017683

Which suggests big keys needs to be enabled for kernel and suggests kernel 3.11
However, RHEL-7 is based on 3.10 kernels - do we know whether big Kerberos keys 
are supported there?


$ grep big_key /proc/keys

I'd say that was a yes.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Adding service to sssd + AD

[John Hodrien]

On Thu, 21 Jul 2016, Ondrej Valousek wrote:


Try "net ads keytab add afs" - but it's probably not going to work without
admin privileges in AD.


Domain Admin is *definitely* not required for this, but obviously you do need
a credential with sufficient rights.  The machine's credential itself is
probably sufficient.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Dear lazyweb... not getting cached ticket from PuTTY login

[John Hodrien]

On Thu, 21 Apr 2016, Sumit Bose wrote:


On Thu, Apr 21, 2016 at 10:13:20AM +0100, John Hodrien wrote:

On Thu, 21 Apr 2016, Sumit Bose wrote:

>In this case SSSD has nothing to do with ccache handling, everything is
>done by sshd.

I was suspicious about windows not providing a forwardable ticket by default,
and it not being ssh or sssd's fault.

Have you managed SSO with delegation to a machine not running sssd using
putty?


ah, this reminds me that the host must be configured to be trusted for
delegation, see AD's 'AD Users and Computers' tool, find your target
host and check the 'Delegation' tab.


We see a failure connecting from a windows machine with putty, but success
from a linux machine.  Neither machine appears to be configured for delegation
within AD (both listed as Do not trust this computer for delegation).

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Dear lazyweb... not getting cached ticket from PuTTY login

[John Hodrien]

On Thu, 21 Apr 2016, Sumit Bose wrote:


In this case SSSD has nothing to do with ccache handling, everything is
done by sshd.


I was suspicious about windows not providing a forwardable ticket by default,
and it not being ssh or sssd's fault.

Have you managed SSO with delegation to a machine not running sssd using
putty?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Problem with case sensitivity in Keytab

[John Hodrien]

On Mon, 22 Feb 2016, Patrice Peterson wrote:


Hey list,

I have joined a CentOS 7 host to an AD domain using a fairly new version of
adcli (one of the versions that has this [0] bug fixed). In its keytab, this
host has a service principal of the form 'host/fqdn@REALM' (i.e. lowercase).
User lookups with SSSD don't work, and the SSSD log says "Client
'host/fdqn@REALM' not found in Kerberos database. Unable to create
GSSAPI-encrypted LDAP connection."

However, if I use the 'old' adcli to join the node and create the keytab, it
creates a service principal of the form 'HOST/fqdn@REALM'. With this keytab,
I can do username lookups just fine.

Should this be considered a bug? Is there a way to make service principal
lookups w/SSSD case insensitive? I would like to keep the lower-case
principal names in my keytabs, because OpenSSH GSSAPI auth only works with
those.

Thanks for any pointers!


SSSD with a normal AD joined machine would use the SHORTHOST$@REALM entry, not
any of the others.  That one's the only one that's a userPrincipal by default
(although you can choose *one* additional userPrincipal if you require).

You can test this on the command line as it's the only one kinit -k will work
with:

# These work
kinit -k SHORTHOST$ 
kinit -k SHORTHOST$\@DS.LEEDS.AC.UK


# These do not work
kinit -k host/fqdn
kinit -k host/fqdn\@DS.LEEDS.AC.UK

So I'm not entirely sold on your diagnosis being correct.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: sssd, openldap, tls, multiple servers?

[John Hodrien]

On Thu, 11 Feb 2016, Liam Gretton wrote:


A better approach in my opinion is to load balance your LDAP servers and use
a single address for your clients to point at. That way as your organisation
or load grows you can just throw additional peers at the LDAP end and not
worry about how the clients are configured.

keepalived and haproxy will do this very nicely.


What does that offer over using SRV records?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: sssd, openldap, tls, multiple servers?

[John Hodrien]

On Thu, 11 Feb 2016, Liam Gretton wrote:


On 11/02/2016 16:00, John Hodrien wrote:

keepalived and haproxy will do this very nicely.


What does that offer over using SRV records?


That's another way of doing it, I think that's what Active Directory
does, correct?


Yes.  Paired with "sites", you get a fairly flexible method for balancing
usage.


With HA Proxy you get more options for load balancing which can be useful.


SRV works well when a server goes bad.  If server returns a result that tells
the client that there's an error (rather than failing to return a result),
SSSD can mark the server as bad, and try another one.

If they're all hiding behind a single IP, you lose that ability as far as I
can see.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Setting a different $HOME for a specific LDAP user? (Or other solution for dev.)

[John Hodrien]

On Mon, 1 Feb 2016, Magnus Therning wrote:



I've just come across SSSD and have managed to set it up for use against
our LDAP server. Yay!

We have LDAP set up for user and group management, and all users' homes
live on an NFS share. This is fine for me most of the time, except for
on the machine where I do development; I really don't like to run the
compiler against files on NFS!

I see three options

1. Use a local user, with a local $HOME, for development.
2. Create a local dir on the dev machine and use it for all development.
3. Give the LDAP user a local $HOME on the dev machine.

I looked into 3 a bit and found `override_homedir`. It works fine, but
then *all* users on the dev machine get a local $HOME. Is it possible to
override $HOME for a specific user only?


You don't want to override home; you want option #2.  Keep your home directory
on NFS, and keep it backed up and consistent between multiple machines.  Do
development on unbacked up local disk, and commit changes to git/svn repos.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: disable ad backend group filtering? (was Re: Re: speeding up iterative enumeration?)

[John Hodrien]

On Wed, 27 Jan 2016, Stephen Gallagher wrote:


Now, I can certainly see an argument for having such a nosync (or deferred
sync) option for machines that are expected to always be connected to the
identity network (and as such are using SSSD mostly for performance and
surviving the occasional outage hiccup). But I'd say that such an option, if
added, should be VERY carefully documented to explain all of the things that
could go wrong.


I don't disagree with what you've said, and it's exactly this situation I'd be
interested in.  If they're a road warrior, I'd be much less likely to enable
nosync.


As an aside, there are plenty of other things that can go wrong when the cache
is deleted, including manual overrides from the sss_override command as well
as ID ranges if any of them had hash collisions or were using the autorid
compat mode.


Sure, but none of this ends up being worse than using tmpfs, which we
currently resort to in order to get acceptable performance.  nosync with
canary sounds like it can only be better in my situation.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users]Re: Kerberos ticket renewal with AD

[John Hodrien]

On Tue, 1 Dec 2015, Andy Airey wrote:


Hi,

If I read the manpage  correctly, the
setting krb5_renew_interval suggests that the krbtgt gets renewed.

I thought this meant that the ticket gets renewed (a new krbtgt is
generated) before the 7 days come to an end.
Now, 7 days after kinit, we cannot log on tp the machine anymore with our
krb5 credentials.


It'll get renewed regularly, as the valid lifetime of your ticket will be more
like 10/12 hours.  Just do a kinit, then klist, and see what it tells you.
You can ask for a longer life ticket, but AFAIK AD defaults to a max of 7
days.  A long life ticket isn't particularly nice from a security point of
view either.


If there is another way, please enlighten me :).


SSSD can renew until it can't.  In your original post you showed:

   "renew until 12/07/15 13:16:40"

You can renew until that point, but you're not allowed to get a credential
valid after that point, so without a password you can feed to the KDC, or
additional privs for the machine, you're done aren't you?

It's doing nothing more than a kinit -R as I understand it, and it's bound by
the same limitations.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users]Re: Kerberos ticket renewal with AD

[John Hodrien]

On Tue, 1 Dec 2015, Thackeray, Neil L wrote:


I’m having this problem as well. This is only happening on Ubuntu machines for 
me, the RedHat and CentOS machines don’t seem to have this issue. I was 
starting to think this might be a problem with Kerberos libraries or something, 
otherwise I can’t understand why it wouldn’t work only on Ubuntu.

I monitor when one of my servers loses contact with the AD by running a cron 
script every 10 minutes:
#!/bin/bash

HOST=`hostname`
TST=`kinit -k 'SERVERNAME $@AD.MYDOMAIN.COM' 2>&1`
if [ "$TST" != "" ]; then
   logger -p user.crit "SSSD AUTH ERROR: [$DATE] $TST on $HOST"
   DATE=`date`
   echo "[$DATE]" $TST>>/root/sssd-weirdness.txt
fi


Have you got something in AD mandating machine password changes, or do you
have something like msktutil running doing it for you?

jh___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users]Re: Kerberos ticket renewal with AD

[John Hodrien]

On Tue, 1 Dec 2015, Thackeray, Neil L wrote:


I don't control the AD, but I looked and couldn't find a policy mandating
machine password changes outside of the standard time. I am not running
msktutil, but I don't really see why I should have to. This is what sssd is
supposed to be doing for me, and it's working just fine in CentOS and RedHat
out of the box.


You *shouldn't* need to, but if something was periodically updating the
machine password on this machine of yours, as is the norm with windows, and as
can be acheived with certain tools, and wasn't updating the keytab, you'd
presumably see this.

This isn't an SSSD issue.

Your issue is that your keytab isn't valid after a week.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users]Re: Kerberos ticket renewal with AD

[John Hodrien]

On Tue, 1 Dec 2015, John Hodrien wrote:


On Tue, 1 Dec 2015, Thackeray, Neil L wrote:


 I don't control the AD, but I looked and couldn't find a policy mandating
 machine password changes outside of the standard time. I am not running
 msktutil, but I don't really see why I should have to. This is what sssd
 is
 supposed to be doing for me, and it's working just fine in CentOS and
 RedHat
 out of the box.


You *shouldn't* need to, but if something was periodically updating the
machine password on this machine of yours, as is the norm with windows, and 
as

can be acheived with certain tools, and wasn't updating the keytab, you'd
presumably see this.

This isn't an SSSD issue.

Your issue is that your keytab isn't valid after a week.


When it breaks, do a klist -k to see the current state of your keytab.

Then do a:

kvno HOSTNAME$

Those numbers should match.  If kvno returns a higher number, then something
has changed the password and not updated the keytab.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

Re: [SSSD-users] sssd fails - too many open files

[John Hodrien]

On Thu, 12 Nov 2015, Ondrej Valousek wrote:


Hi,
It’s a known bug – will be fixed in 6.8.


What triggers the bug?

jh___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] SSSD & AD & Kerberized nfs

[John Hodrien]

On Tue, 20 Oct 2015, John Beranek wrote:


Can't really see how to solve that and leave the Isilon load balancing
in place. :(


Can you explain simply how your load balacing is working?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] SSSD & AD & Kerberized nfs

[John Hodrien]

On Tue, 20 Oct 2015, Ondrej Valousek wrote:


Will add this to my document, thanks.
I have heard about this issue - but how many is "many groups"?
I have user here with 32 groups - I do not experience any problems.


I'm not sure.  150 is definitely too many groups.  Yes, it's definitely too
many groups even without NFS.  It's related to whether the PAC fits in a page
AFAIK.

The other part of the fix with AD, one you have these two computer objects:

myhost
myhost-nfs

ktpass -princ nfs/myhost.domain@REALM -mapuser myhost-nfs$ +rndPass -out 
temp.keytab -crypto ALL

That then gives you a keytab to merge into the first, so on the client it
looks like a perfectly normal setup.

I don't know whether you can do this all from the linux side.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Race condition when /var/lib/sssd in on NFSv4

[John Hodrien]

On Wed, 23 Sep 2015, Ondrej Valousek wrote:


Understood. Once SSSD is in shape good enough for it. I will put /var/lib/sssd 
on tmpfs.
For now, I have to decide between two bad options.


Could you not whip the cache into a shape where it masks your issue, then save
that to pre-populate the tmpfs?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Tokengroups usage

[John Hodrien]

On Fri, 18 Sep 2015, Ondrej Valousek wrote:


Hi List,

Man sssd-ldap says:
"
If ldap_group_nesting_level is set to 0 then no nested groups are processed
at all. However, when connected to Active-Directory Server 2008 and later it
is furthermore required to disable usage of Token-Groups by setting
ldap_use_tokengroups to false.
"

Why is usage of tokengroups not possible with Windows server 2008 or newer?
Can someone clarify?


That's not what it means.  If you have tokengroups enabled, you get fully
nested group handling as a result.

If you want to disable nested group handling, you have do disable both
tokengroups and set ldap_group_nesting_level to 0.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] kerberized nfs4 with sssd id mapping

[John Hodrien]

On Thu, 17 Sep 2015, Isaiah Houston wrote:


Has anyone else experienced this? I saw there was some effort at an sssd
plugin for rpcidmapd, but that doesn’t seem complete yet. Is there a viable
workaround so I can get kerberized nfs mounts up?


Without use_fully_qualified_names, I've had no problems with krb5 NFSv4 and
sssd.

Only thing I do to deal with >16 groups is this on the server:

/etc/sysconfig/nfs:
RPCMOUNTDOPTS="--manage-gids"

We're running rpc.idmapd on the server, but not on the client.

jh___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] gidNumber resolution problem

[John Hodrien]

On Tue, 14 Jul 2015, Rowland Penny wrote:

Failing the inept windows admins changing AD, I would suggest that you set up 
your own Samba4 AD DC.


If I was working around an AD I had no control of that was setup like this:

In sssd.conf:
# Typically this is set to 513 (Domain Users)
ldap_user_gid_number = primaryGroupID

Or:
override_gid = 513

Add Domain Users to /etc/group:

Domain Users:x:513:

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] caching question? (switching servers)

[John Hodrien]

On Tue, 23 Jun 2015, Janelle wrote:


Servers are behind a load-balancer. Address never changes.


But one problem with that is that SSSD will see multiple servers as one
server, and so will mark the server as failed if the load balancer presents it
with a broken back end server.

Works much better in my experience when you tell SSSD about all the servers.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] SSSD and Dynamic DNS - clarification

[John Hodrien]

On Mon, 22 Jun 2015, Frank Pikelner wrote:


The second /etc/hosts file should be correct but dynamic DNS is not
working. Is there something in the implementation that requires the first
case, or should just the order of the /etc/hosts entries modified so that
the localhost appears second in the list?


I have machines that do DDNS triggered from DHCP, and it works just fine
without having the incorrect /etc/hosts.  Indeed I just have:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

To get the client to send the correct hostname, I use:

/etc/sysconfig/network-scripts/ifcfg-eth0:
DHCP_HOSTNAME=whatever.you.want

That makes it work perfectly for me.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] net ads join custom keytab

[John Hodrien]

On Thu, 30 Apr 2015, Ondrej Valousek wrote:


Just trying to make sssd working in the diskless environment. As such, I
need to create Kerberos keytab on non-standard location:


You considered just using tmpfs to have it in the standard location?  That's
the standard stateless linux diskless way of doing things, and has always
worked out ok for me.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] net ads join custom keytab

[John Hodrien]

On Thu, 30 Apr 2015, Ondrej Valousek wrote:


Yes, I am using it heavily, but not for /etc. I need /etc to stay read-only
so that it could be shared by multiple compute nodes.


You can effectively do it for single files.  On CentOS you can look at
rc.sysinit, and the mount_files function.

You'll not /etc/rwtab lists things like /etc/resolv.conf, so you don't have to
hit all of /etc.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] net ads join custom keytab

[John Hodrien]

On Thu, 30 Apr 2015, Ondrej Valousek wrote:


I know.
The thing is, that krb5.keytab can't go to rwtab - it would have to go to 
statetab (I need this file survives a reboot).
Unfortunately, statetab does not seem to handle single files correctly... :(


Shame, it definitely looks like it tries to:

for file in /etc/statetab /etc/statetab.d/* ; do
  is_ignored_file $file  continue
  [ ! -f $file ]  continue
  if [ -f $STATE_MOUNT/$file ] ; then
mount -n --bind $STATE_MOUNT/$file $file
  fi

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Trouble with password authentication of AD users

[John Hodrien]

On Wed, 1 Apr 2015, Orion Poplawski wrote:

A mistake in an AD update set it to that.  Obviously it should be 
or...@ad.nwra.com, and is fixed now.  Do you still want the kinit trace for 
this configuration error?


I still see this as a bug in the AD provider.  userPrincipalName in AD does
*not* reliably map to the name of the user Principal.  It's an alias for the
username you can use at login, but it doesn't relate to kerberos AFAIK.

With our ldap/krb5 config (that we've *still* not switched over to use the ad
provider), we use:

ldap_user_principal = checkundefinedattribute

This was, it hits an undefined attribute, and simply defaults to the
reliably correct value.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd troubles under load

[John Hodrien]

Yes.  This is a mode we have used for performance gains, and without a reboot, 
it'll behave entirely the same as normal.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] idmaping, AD multi domain forest

[John Hodrien]

On 20 Jan 2015 10:28, Longina Przybyszewska long...@sdu.dk wrote:

 Thanks for your answer-you sound very sceptic so I would be very happy if you 
 can deepen your meaning;
 Is my goal  possible to achieve, is this the right strategy?? -
 to integrate Linux into AD with SSSD ,  NFS mounted homedir with Kerberos 
 security,  cross realm authentication,
 with Posix attributes for user/group objects in AD .

 I have to mention that my boss supports me, and my MS-admin colleagues  have 
 a positive attitude for the project.

I've done all of that other than the cross realm bit, and it works like a charm.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] SSSD-AD: SamAccountName 20 character limit - What does SSSD do with longer host names?

[John Hodrien]

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
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] SSSD-AD: SamAccountName 20 character limit - What does SSSD do with longer host names?

[John Hodrien]

On Thu, 20 Nov 2014, Joschi Brauchle wrote:


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.


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
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] SSSD-AD: SamAccountName 20 character limit - What does SSSD do with longer host names?

[John Hodrien]

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
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Client randomly losing GID information on NFS files w/ 1.12.1

[John Hodrien]

On Mon, 10 Nov 2014, Jakub Hrozek wrote:


At the same time, I wonder why the GID is being reported as 4294967294,
isn't that nfsnobody or a similar 'fallback' user?


If rpcidmapd can't work it out, it'll fall back to a nobody user.

In my case I saw this linked to BZ#1033708, which wasn't SSSD's fault.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Announcing SSSD 1.12.2

[John Hodrien]

On Tue, 21 Oct 2014, Simo Sorce wrote:


As work around you could force install RHEL's native i686 client. The
client protocol hasn't changed (not in incompatible ways anyway) so it
should keep working.


Ah okay, that's well worth trying, thanks.  I just want to have a full setup
for testing EL7 with our setup and the version that ships is currently a no-go
because of the tokengroups issues I had.  A newer 1.12 definitely fixed all my
problems, but I was looking for the missing bit as that was breaking some
32bit apps.  If I can just force install the old client, that's absolutely
fine for now.

jh

--
John Hodrien
Specialist IT and Unix, IT
Faculty of Engineering
0113 3435471
9.26 EC Stoner
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Install newer version of SSSD on CentOS 6.5

[John Hodrien]

On Fri, 17 Oct 2014, Eric VS wrote:


Hi all,
I'm using SSSD for authentication against AD and it works like a charm so a
big thanks to all the developers. One thing I'm missing out on is the newest
options. CentOS 6.5 comes with version 1.9.2 of SSSD. The option I'm looking
for is the 'ad_access_filter' one which allows me to filter out which users
get access. I've been looking for an RPM for CentOS 6 for at least version
1.11 for which is running on my machine and has the desired option but
cannot find it.

Any other options? Or anyone can point me to what I can do for an
alternative? 


access_provider = simple
simple_allow_groups = some-group

You also can presumably use:

ldap_access_filter (look at man sssd-ldap).

Wait a few days for 6.6?

jh___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd, ldap, huge server load

[John Hodrien]

On Tue, 7 Oct 2014, François Dagorn wrote:


Attached the log file with debug=9 and also our sssd.conf.


Do you have a really good reason to enable enumerate?

jh___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] root login with domain passwd

[John Hodrien]

On Fri, 26 Sep 2014, steve wrote:


Doesn't work here. Maybe it needs pam_krb5?


Works here just fine, but I presume you need GSSAPI enabled in sshd_config,
since this'll get handled before PAM gets involved won't it?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] root login with domain passwd

[John Hodrien]

On Fri, 26 Sep 2014, Joakim Tjernlund wrote:

  Why is it so hard to keep me on CC? Some list setting which makes 
this easy to forget?


Because the list is well configured with a reply-to set to the list.

If you want to be part of a list, why not just join the list for the period
you want to interact with it, rather than cause unnecessary work for people
you're trying to communicate with?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] root login with domain passwd

[John Hodrien]

On Fri, 26 Sep 2014, Joakim Tjernlund wrote:


Possibly one can do that, but this is just a bad workaround for a bad
assumption in SSSD, namly that there can not be any system out there who
would like to auth root with SSSD.


You're a corner case that goes against normal practice, so any workaround is
fine, however grim.  You can use .k5login/ssh keys/sudo and get to a better
place than you're aiming for with this solution, and you don't have to modify
sssd and pam to work in non standard, and most likely non-LSB compliant ways
to make it work.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] root login with domain passwd

[John Hodrien]

On Thu, 25 Sep 2014, Jakub Hrozek wrote:


If your goal is to have the same root password across an enterprise, I
recommend something like Puppet or Ansible.

If the goal is to let users administer machines, then storing sudo rules
in LDAP is the best way forward.


I'm entirely in agreement with Jakub on this, although to sneak in an answer
that nearly satisfies your query, you /could/ use .k5login to allow them to
login over ssh as root with their kerberos credential.  I don't think that's a
better solution than sudo/puppet though.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] root login with domain passwd

[John Hodrien]

On Thu, 25 Sep 2014, Joakim Tjernlund wrote:


Because as an admin I need to login on users boxes to fix stuff they broke.
Sometimes su/sudo are not setup/broken too.



If your goal is to have the same root password across an enterprise, I
recommend something like Puppet or Ansible.


How does that help me to ssh in and what if Puppet/Ansible is not 
setup/broken?

Not every box is installed the same.


If every machine is different, and you can't be sure su/sudo are working, and
you don't know the local root password, I'd not have a lot of faith that sssd
would be working.  Add to that, you're talking about breaking best practice as
I'd prefer to see root password based logins disallowed.

If you want the lightest touch setup that gets you what you want, I'd just
stick a /root/.ssh/authorized_keys file on every machine's root account.
That'd work just fine with sssd, and unless ssh is broken, and the local admin
has deliberately deleted that file, you'll get in.  You'll get into a much
more broken system with that than you would relying on sssd.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] root login with domain passwd

[John Hodrien]

On Thu, 25 Sep 2014, Joakim Tjernlund wrote:


is, which is why ssh provides the option:

AllowRoot without-password


Why would I want to enable that?


Because it's more secure than the default of allowing root logins with
password remotely.  But forget it, it's not entirely ontopic, as I'd partially
misread what you'd said.


That is a choice I got in PAM, sssd offers no choice.

Still, I don't see how the above somehow documents sssd's
no root login whatsoever policy. The docs actually hints the
opposite:
filter_users, filter_groups (string)
Exclude certain users from being fetched from the sss NSS database. This
is particularly useful for system accounts. This option can also be set
per-domain or include fully-qualified names to filter only users from the
particular domain.
Default: root

This make me think I only have to add an empty filter_users to allow root


Sure, the documentation encouragages you to think you could disable it, and if
that's not the case, it's a flaw in the documentation.

Maybe you've got a point that sssd should allow this unusual setup.

jh

--
John Hodrien
Specialist IT and Unix, IT
Faculty of Engineering
0113 3435471
9.26 EC Stoner
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] root login with domain passwd

[John Hodrien]

On Thu, 25 Sep 2014, Joakim Tjernlund wrote:

Yes, it is my job, not sssd's. Currently sssd dictate that no system 
ever should be allowed to login as root, no matter what.


SSSD dictates that no system should be allowed to login as root via SSSD, and
that's not quite the same.  You're a corner case where you're working against
standard practice, but I can see why you think it should be possible to
configure SSSD to allow it, given that you can strip away these sanity checks
from PAM.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd and sudo ldap problems with IPA.

[John Hodrien]

On Thu, 28 Aug 2014, Simo Sorce wrote:


auth_provider = krb5
chpass_provider = krb5
krb5_realm = IPA.EXAMPLE.TEST
krb5_server = ipa-host.ipa.example.test


Without a keytab validation is not possible, that's not ideal.


Depending on your reason for not joining a machine to the domain, you're free
to share a single kerberos lookup credential via a keytab between multiple
machines, will still gives you the ability to validate.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd and sudo ldap problems with IPA.

[John Hodrien]

On Fri, 29 Aug 2014, Simo Sorce wrote:


Although if one of the machines is compromised, now you can fool the
others, still better than no validation at all.


If I give you a null/unused.hostname@DOMAIN credential in a keytab, what can
you fool?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd with ad backend, pam problems

[John Hodrien]

On Thu, 28 Aug 2014, Stefan Schäfer wrote:

authconfig is part of fedora and red hat, but not of openSUSE and sles. 
Here you have to configure this with yast or by hand. YaST didn't know 
anything about sssd_ad yet.


Ah yes, good point.  Perhaps pam-config?

jh___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] NFS+KERB+SSSD Ubuntu 14.04

[John Hodrien]

On Mon, 11 Aug 2014, Longina Przybyszewska wrote:


No, not that simple ;( - sorry for  typing  fail.

Mount command:
mount  -t nfs4 -o rw,sec=krb5 jota.nat.c.example.com:/nfs /nfs

or 'mountall' with the following entry in /etc/fstab :

jota.nat.c.example.com:/nfs /nfsnfs4 rw,sec=krb5 0 0

On server /etc/exports:
/nfs*(rw,crossmnt,no_subtree_check,sec=krb5)

I can't see there is a 'user' option for nfs mount.


I fail to see how SSSD can be to blame for any of this, as the mount has
nothing to do with mapping users.

I've always gone for an nfs/fqn userPrincipal for both client and server,
which I understand to be a touch outdated with current nfs-utils.  If you're
using AD, it's also important to set the userAccountControl to limit the
kerberos tickets to not include PAC, or else you'll have issues with user
accounts that are members of a significant number of groups.

I think the significant bit is Wrong principal in request on the server.

Possibly things to check:

Check kvno lines up correctly for all machine credentials.  When in doubt,
delete the machine objects and start again.

Previously NFS was very limited in what enctypes it could cope with.  Try
again with:

[libdefaults]
default_tkt_enctypes = arcfour-hmac

set in krb5.conf at both ends.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] NFS+KERB+SSSD Ubuntu 14.04

[John Hodrien]

On Mon, 11 Aug 2014, steve wrote:


Maybe easier to delete both server and client keytabs and recreate them.
You can save a bit of time since the nfs/ key is necessary only on the
server. The client is happy with MACHINE$.


As long as you have sufficiently recent nfs-utils, which in this case you
almost certainly do.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Using sssd on HPC cluster without direct ldap access

[John Hodrien]

On Wed, 16 Jul 2014, Dmitri Pal wrote:

Potentially what you want is to be able to generate SSSD cache db on one 
system and copy it around.
There is no such functionality and the problem with building one is 
creating password hashes in such database in bulk (requires passwords in 
clear which is a nonstarter). When users log in one by one passwords can 
be captured and hashed for further use. It is hard to do in bulk.


I'd argue that there's normally no need to do internal authentication within
an HPC cluster, user information alone is sufficient.  Internally, you can
rely on the integrity of the cluster to get by with trusted auth between the
nodes, and HostbasedAuthentication or similar.

May be what you can do is make users log into the gateway node and then 
once a while copy its sssh caches to other nodes in the cluster but SSSD 
on those nodes would be outdated for that period of time. I do not know 
how usable it is. A new user would have to wait for this period after he

authenticated and before he actually can submit a job. May be you already
have a mechanism to queue these things. May be you can somehow detect that
user is new and queue the SSSD cache update together with his actual job.


I'm not clear what benefit you get from running SSSD internally, vs a cluster
local NIS/LDAP fed data from an SSSD front node.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] LDAP access provider - list of groups in directory?

[John Hodrien]

On Thu, 10 Jul 2014, Stephen Gallagher wrote:


John, this would actually be a rather interesting idea, but I agree
with Dmitri: if this is the level of control that you need, you would
be in a far better position with FreeIPA/Red Hat Identity Management.
It has this concept baked into its Host-Based Access Control mechanism
(which SSSD fully supports). The problem with trying to do this in
plain LDAP is that there exists no standard mechanism for maintaining
this sort of information on the LDAP server (FreeIPA's HBAC rules are
kind of a de-facto standard).


By adding a group to AD per machine with suitable members, and using simple to
restrict access to that group, are you not in the same place, albeit with an
extra object in LDAP?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] LDAP access provider - list of groups in directory?

[John Hodrien]

On Thu, 10 Jul 2014, Dmitri Pal wrote:

No. HBAC is much more flexible. At uses groups of systems and groups of 
users so you have to create and maintain much less objects.


Right yes, that does sound neater, and fewer objects is always good.


But in previous email you said OpenLDAP now you say AD. I am confused.


I'm probably not the John you're looking for.  I was just curious.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] using SSSD with nscd

[John Hodrien]

On Wed, 11 Jun 2014, Daniel Jung wrote:


According to the redhat/fedora doc on this subject is to suggesting that
sssd is not meant to run with nscd but could be ran with nscd caching host
only and rest to sssd. Curious to hear of lists opinions on this setup.
Benefits of not runnig nscd at all and run sssd only and use no nscd at
all. 


Yes.  I've run it in that mode, and had no bother.  In the end, I switched to
dnsmasq running locally, as nscd's caching of host data is, as far as I knew,
totally crap.

jh

--
John Hodrien
Specialist IT and Unix, IT
Faculty of Engineering
0113 3435471
9.26 EC Stoner___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] ddns updates not required?

[John Hodrien]

On 7 Jun 2014 18:38, steve st...@steve-ss.com wrote:
 Hi
 Thanks.
 Yes, same here. Even though bind allows the signed updates from sssd, we
 don't need them. We can authenticate using sssd no matter what IP is
 assigned and no matter what is stored in AD. Maybe the ddns requirement
 could be removed from the default ad-backend?

You can hijack a keytab from another machine and use it for sssd, so correct 
DNS really doesn't matter for pure sssd operation.  You'll only cause bother 
for things using kerberos auth as a service (say samba/http/NFS/SSH), which if 
you like such things is a big deal.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]

[John Hodrien]

On Thu, 22 May 2014, steve wrote:


/etc/hostname has to contain the fqdn, not the hostname. So now,
hostname
is wrong
but
hostname -s
and
hostname -f
return correctly.

More importantly, the ddns updates go fine.
However, I'm sure that'll break something else somewhere else down the line.

What is also worrying is that even with a non-updated DNS, we could 
still log in, reach the file server, get tickets etc.


This is only on Ubuntu 14.04. openSUSE works fine with the short 
hostname in /etc/hostname.

Any comments?


shorthostname in /etc/hosts as the primary is wrong.  fqdn should be first
entry, followed by aliases.

hostname returning fqdn is correct behaviour.

jh

--
John Hodrien
Specialist IT and Unix, IT
Faculty of Engineering
0113 3435471
9.26 EC Stoner
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]

[John Hodrien]

On Thu, 22 May 2014, Rowland Penny wrote:


Not on Ubuntu it isn't ;-)


I'd argue that Ubuntu just has incorrect behaviour then.

If you look at man hosts on an ubuntu machine (13.10), you'll see how they
describe it, and the example they provide.  The format described is:

IP_address canonical_hostname [aliases...]

The example is:

127.0.0.1 localhost
192.168.1.10  foo.mydomain.orgfoo
192.168.1.13  bar.mydomain.orgbar

That's the correct format, whether or not Ubuntu applies it.

That said, the only machine I have with ubuntu defined a hosts file with:

127.0.1.1 short-ubuntu-13.10  short-ubuntu-13

That, in a slightly unpleasant way, follows the way I'd do it.

jh

--
John Hodrien
Specialist IT and Unix, IT
Faculty of Engineering
0113 3435471
9.26 EC Stoner
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] New AD provider howto

[John Hodrien]

On Fri, 25 Apr 2014, steve wrote:


On Thu, 2014-04-24 at 16:33 -0400, Jeremy Agee wrote:

On 04/23/2014 05:25 AM, John Hodrien wrote:

 This is a guide for setting up against AD.  Is there *any* realistic
 circumstance where SHORTNAME$@REALM won't be available?


If someone was creating the keytab on the windows side using ktpass like 
the example in the Creating Service Keytab on AD section this could be 
needed.  This is less common though and your correct in most setups it 
would not be needed. The powershell script in that same section would 
create both a host/fqdn@REALM and SHORTNAME$@REALM principle with a UPN, 
so the extra config line would not be needed if the keytab was create by 
ktpass in this way.


Hi
One other circumstance could be with a samba net ads join from a
previous domain join where smb.conf did not include at least:
kerberos method = system keytab
line.
Under these circumstances it would be necessary to issue:
net ads keytab create
to get the machine (and host/) key.


Yep, I can see that one.

I guess I'm personally not keen for this document to be a guide on undoing
unknown broken practice.  I equally could have changed the userAccountControl
to break kerberos by only allowing unusable enctypes or similar, but I don't
think this should go into those details.  Or joining when there was an
existing record in AD for a previous windows machine.

Freaky setups will go outside this document, whatever you do, but I'd choose
to have that document as lithe as possible.  realmd/samba/ad-server approaches
are all listed as valid in different cases, with justification for why that is
so.

I might also prefer a bit of a restructure as I think it's a little confusing
at the minute what is required:

Joining to AD:
 - realmd (does everything)
 - manual setup
   - generate keytab with samba
   - generate keytab on ad server

jh

--
John Hodrien
Specialist IT and Unix, IT
Faculty of Engineering
0113 3435471
9.26 EC Stoner
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] New AD provider howto

[John Hodrien]

On Thu, 10 Apr 2014, Jakub Hrozek wrote:


our current HOWTO[1] on connecting SSSD to an AD DC is outdated,
mostly because the page still only introduces the LDAP provider. Recently, me,
Sumit and Jeremy Agee wrote a new page that specifically advises to use
the AD provider and also use realmd for setup:
https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server

We started a new page and kept the old one around mostly because pre-1.9
versions still need the LDAP provider info.

I'd like to get some review and feedback from our community so we can
link the wiki page from the front page or the documentation section. In
addition to the lists, I also CC-ed the individual contributors to the
original page directly..I hope that's fine.

Thank you for your comments.


Sorry for the delay in replying, I was off on holiday so hadn't had a chance
to properly look through this.  The only thought I'd had so far in addition to
what's been said was that I didn't like the wording in one section:

# Uncomment and adjust if the default principal SHORTNAME$@REALM is not # 
available
# ldap_sasl_authid = host/client.ad.example@ad.example.com

This is a guide for setting up against AD.  Is there *any* realistic
circumstance where SHORTNAME$@REALM won't be available?

I'd gleefully delete those two lines.

A minor issue is a slight mix of true/True/false/False.  Can we pick one (I'm
guessing you prefer True/False).

Possibly some more warnings around the userPrincipalName string attribute,
which doesn't have to map to a user principal at all, so is a possible grenade
that'll screw the setup.

jh

--
John Hodrien
Specialist IT and Unix, IT
Faculty of Engineering
0113 3435471
9.26 EC Stoner
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd-1.11.1 Trusty automount nfs4+krb+sssd problem

[John Hodrien]

On Thu, 27 Feb 2014, Longina Przybyszewska wrote:


Hi,
Ubuntu Saucy  nfs4+krb+sssd server
Ubuntu Trusty client,sssd+autofs

I can manually mount directory (nfs4+krb) as root on the client.

Is it possible on client,  use SSSD with autofs service,  with  automounter 
referring to the flat files ,
/etc/auto.master ,/etc/auto.home, not to ldap?

How can I check if autofs delivered with distribution supports sssd?


If you only want flat files, why does sssd have to be in any way involved with
autofs?

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)

[John Hodrien]

On Wed, 12 Feb 2014, Longina Przybyszewska wrote:


Do I miss something in getting point here:

If there is a key  for the principal 'host/client.domain@domain.org' in 
local /etc/krb5.keytab -

why there are no credentials in Kerberos database?


ServicePrincipal vs UserPrincipal.  In AD, you can add as many service
principals as you like (net ads keytab add blah), but these are only useful
for services, as they can't get a Ticket Granting Ticket.  NFS is unusual in
needing a tgt.  So you have ones like host/fqdn which can be used by ssh.  You
get one user principal for free with AD, which is 'shorthostname$'.  That can
generate a TGT (i.e. you can use kinit with it).  You're allowed one other,
which you can generate with samba via 'net ads join
createupn='something/fqdn'.  This can be useful for services that need it,
that don't know to use the other one.  So you can use that with nfs to make it
all happy that way, by making the nfs/fqdn principal able to request a tgt.


Is this because for NFS4 service machine  asks, there is need for
credentials for machine principal,  the one ending with “$”, and rpc.gssd

asks about  CLIENT.DOMAIN.ORG$@DOMAIN.ORG instead of CLIENT$@DOMAIN.ORG

and that question  depends on what ‘hostname’ returns?


hostname should always return the full hostname, and hostname -s should return
the short host name.  I'd really not change that to fix this problem.

jh___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] kinit: Client not found in Kerberos database

[John Hodrien]

On Wed, 18 Dec 2013, Jakub Hrozek wrote:


btw keytabs that are generated with Samba or realmd should already
contain this principal. In general, I think using Samba or realmd is
even easier and should be recommended.


I couldn't agree more with this.  Unless you're making keytabs that are
sufficiently interesting that samba or realmd can't make them, you really
don't want to complicate matters by getting your hands dirty.

It's much easier using samba to do it, significantly faster, and it's less
prone to error.  They also work exactly the same if you have domain join but
not domain administrator rights.  Done with samba or realmd, it's a single
line in my kickstart to join the machine to the domain and generate the
keytab, and I know it's right everytime it happens.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] kinit: Client not found in Kerberos database

[John Hodrien]

Sender: sssd-users-boun...@lists.fedorahosted.org
On-Behalf-Of: j.h.hodr...@leeds.ac.uk
Subject: Re: [SSSD-users] kinit: Client not found in Kerberos database
Message-Id: alpine.lrh.2.03.1312180937330.31...@yrrqf.np.hx
Recipient: cklopotow...@crabel.com
---BeginMessage---

On Wed, 18 Dec 2013, Jakub Hrozek wrote:


btw keytabs that are generated with Samba or realmd should already
contain this principal. In general, I think using Samba or realmd is
even easier and should be recommended.


I couldn't agree more with this.  Unless you're making keytabs that are
sufficiently interesting that samba or realmd can't make them, you really
don't want to complicate matters by getting your hands dirty.

It's much easier using samba to do it, significantly faster, and it's less
prone to error.  They also work exactly the same if you have domain join but
not domain administrator rights.  Done with samba or realmd, it's a single
line in my kickstart to join the machine to the domain and generate the
keytab, and I know it's right everytime it happens.

jh
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
---End Message---
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users