[SSSD-users] Re: Ubuntu Bionic - sssd 1.16.1 - kerberos ticket not renewing

[Jakub Hrozek]

On Wed, Oct 31, 2018 at 08:20:55PM +, Jay McCanta wrote:
> Yes.  Kinit -R renews the ticket (if it hasn't expired).

OK, can you attach a snippet of the logs? I thiknk the domain log and
the krb5_child.log are the most important.
___
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: Ubuntu Bionic - sssd 1.16.1 - kerberos ticket not renewing

[Jakub Hrozek]

On Thu, Nov 01, 2018 at 05:20:57PM +, Jay McCanta wrote:
> I have the snippets.  May I mail them to you directly.  I was trying to 
> cleanse them, but I'm afraid I'm changing them too much.  

Yes, sure.
___
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: Id vs ldapsearch

[Jakub Hrozek]

On Tue, Nov 06, 2018 at 05:22:52PM -0500, Tom wrote:
> Just a general question about the behaviour of sss_cache , is and ldapsearch.
> 
> Id will return say 8 groups and for the same user ldapsearch will return 10.
> 
> Now as long as if returns 8 apps report authentication denied because the 
> user is not in an expected group.  Now when we run sss_cache -E to invalidate 
> the cache, id Will now return all 10 groups.
> 
> Now the group change was done days ago and our entry_cache_timeout is at 
> default of 5400.
> 
> Why do we still need to run sss_cache -E if the timeout should take care of 
> things?  We are directly authenticated against AD via computer objects.  
> 
> Just asking a general question as I’m curious how this works.  

Sounds like an issue, can you capture it with logs?
___
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: SSSD in AIX

[Jakub Hrozek]

On Mon, Nov 12, 2018 at 03:57:53PM +0530, Ayappan wrote:
> Hi,
> 
> I am from AIX OS development team here in IBM. We have some customers
> who are interested in running SSSD in AIX. So i basically invested
> some amount of time to first build SSSD in AIX. I built the recent
> version 1.16.3 after working around some build issues. Below is the
> configure options.
> ./configure --prefix=/opt/freeware --disable-cifs-idmap-plugin
> --without-nfsv4-idmapd-plugin --disable-rpath --with-manpages=no
> --without-python3-bindings --with-selinux=no --with-semanage=no
> --with-crypto=libcrypto --without-secrets --without-kcm
> 
> I started the daemon but then it failed later with no stderr / logs
> produced anywhere.
> 
> # /opt/freeware/sbin/sssd -i -d4

Are there also no messages if you run with -d 10 ?

On Linux, I would have said that strace with -ff would be also helpful,
but I have no idea if something like this exists on AIX.

> 
> (1) root @ fvt-p7a2-lp16: /
> 
> I see it invokes two other child process which also failed
> /opt/freeware/libexec/sssd/sssd_be --domain implicit_files --uid 0
> --gid 0 -d 0x01f0 --logger=stderr
> /opt/freeware/libexec/sssd/sssd_nss --uid 0 --gid 0 -d 0x01f0 --logger=stderr
> 
> Any help would be appreciated.
> 
> Thanks
> Ayappan P
> ___
> 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 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: SSSD login delay

[Jakub Hrozek]

On Mon, Nov 12, 2018 at 04:25:30PM -, Jonathan Gray wrote:
> Hello,
> 
> We need help debugging this issue.
> 
> For some servers we're experiencing over 10 second delay logging in with IPA 
> user.
> Since the issue isn't present everywhere we're finding it hard to debug.
> 
> 
> SSSD config looks like this::
> 
> [domain/hostname.com]
> 
> cache_credentials = true
> krb5_store_password_if_offline = true
> ipa_domain = hostname.com
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ldap_tls_cacert = /etc/ipa/ca.crt
> ipa_hostname = hostname.com
> chpass_provider = ipa
> dyndns_update = True
> ipa_server = ipa1-hostname, ipa2-hostname
> dyndns_iface = eth0
> dns_discovery_domain = hostname.com
> debug_level = 9
> 
> [sssd]
> services = nss, sudo, pam, ssh
> 
> domains = hostname.com
> [nss]
> homedir_substring = /home
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> 
> [secrets]
> 
> [session_recording]
> 
> We're wondering if there's any obvious configurations we could apply above 
> that would improve SSSD performance

There's no make_sssd_faster=True switch :-), it's hard to give an advise
without at least a little understanding of what might be the root cause.

In general, login consists of:
- retrieving the user information
- you can simulate the worst case by running "sss_cache -E; id
  $username". Above you said that the user is an IPA one, does the
  user really come from the IPA directory or e.g. IPA-AD trusts? The
  difference would be that with IPA, the sssd on the clients talks
  directly to the IPA directory server, with IPA-AD trusts the SSSD on
  the clients talks to the DS on the IPA servers which ask SSSD on the
  servers which ask the AD DS.  So in the trust case, typically you want
  to first make sure the servers are fast. If this is the slow piece,
  then look into the SSSD logs for messages like dp_get_account_info_send
  (this is the beginning of a lookup) and dp_req_reply_std (this is
  the end of a lookup). Are there many of these messages or is there
  a long delay between them? Some time ago we also instrumented the
  SSSD code with systemtap probes, so maybe it would be easier to
  run a systemtap script and see what is slow, e.g.
  
http://justin-stephenson.blogspot.com/2017/05/measuring-sssd-performance-with.html

- authentication
- you can simulate the SSSD authentication /partially/ with
  kinit. But SSSD also does some extra steps like verifying the
  TGT comes from the same KDC that issued the keytab. But all in
  all you can look for messages like dp_pam_handler_send for the
  pam request beginning and dp_req_done for PAM request end.

- authorization
- similar to above, dp_pam_handler_send followed by
  SSS_PAM_ACCT_MGMT marks the beginning of the account control check
  and dp_req_done marks the account check end

- session setup
- unless you use FleetCommander to control your desktop systems,
  SSSD typically does nothing in this step

>, and what exactly to look out for in sssd debug logs that would help us with 
>our investigation.

I'd advise to experiment with the lookups, kinit and check the systemtap
scripts or check which PAM phase might be slow for you.

Also, if you have many groups or especially many large groups, it might
be worth a try to suppress group members (ignore_group_members=True)
___
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: sssd with sudo and non posix groups

[Jakub Hrozek]

On Tue, Nov 13, 2018 at 05:00:56PM -0800, Leonard Lawton wrote:
> I have a group in ldap(I'm using 389DS) called "_all" which has a
> groupofnames object class. Members are stored with the uniquemember
> attrtibute. The users in the group are able to login fine via ssh using this
> setup. However, I can't seem to figure out how to get sudo(via ldap) to work
> with my needs.
> The problem seems to be that I am using uniquemember which my configuration
> is not interpreting. I can't use rfc2307 and fall back to posix groups(and
> memberUID) only as I rely heavily on the groupofnames's functionality, so I
> really need to keep that. How can I configure sssd to let me use sudo while
> having a groupofnames as an authoritative source?

Do the groups have a gidNumber? I assume not, otherwise you'd probably
create the groups with the posixGroup objectclass as well.

In general, I don't think sudo allows this, because sudo calls
getgrouplist(3) to see which groups the user belongs to and this call,
being POSIX only returns POSIX groups.

The schema (rfc2307 vs rfc2307bis) is not really relevant, what is
relevant is that the groups must be visible on the OS level, e.g. with
the id(1) call. I guess one way to go might be to create a POSIX group
(sudo_allowed) and add the _all group as a member of this sudo_allowed
group?

> 
> Here is my config:
> 
> [domain/dingos]
> ldap_schema = rfc2307bis
> ldap_group_search_base = dc=dingos?sub?
> ldap_user_search_base = ou=people,dc=dingos
> ldap_uri = ldaps://ldap-server
> ldap_tls_cacertdir = /etc/openldap/cacerts
> sudo_provider = ldap
> ldap_access_filter = (|(memberof=cn=_all,ou=hosts,ou=roles,dc=dingos))
> id_provider = ldap
> auth_provider = ldap
> chpass_provider = ldap
> cache_credentials = false
> access_provider = ldap
> debug_level = 0x3ff0
> ldap_sudo_search_base = ou=SUDOers,ou=roles,dc=dingos
> entry_cache_timeout = 1
> 
> [sssd]
> config_file_version = 2
> services = nss, pam, sudo
> domains = dingos
> ___
> 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 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: SSSD in AIX

[Jakub Hrozek]

On Mon, Nov 12, 2018 at 05:24:54PM +0530, Ayappan wrote:
> On Mon, Nov 12, 2018 at 4:56 PM Jakub Hrozek  wrote:
> >
> > On Mon, Nov 12, 2018 at 03:57:53PM +0530, Ayappan wrote:
> > > Hi,
> > >
> > > I am from AIX OS development team here in IBM. We have some customers
> > > who are interested in running SSSD in AIX. So i basically invested
> > > some amount of time to first build SSSD in AIX. I built the recent
> > > version 1.16.3 after working around some build issues. Below is the
> > > configure options.
> > > ./configure --prefix=/opt/freeware --disable-cifs-idmap-plugin
> > > --without-nfsv4-idmapd-plugin --disable-rpath --with-manpages=no
> > > --without-python3-bindings --with-selinux=no --with-semanage=no
> > > --with-crypto=libcrypto --without-secrets --without-kcm
> > >
> > > I started the daemon but then it failed later with no stderr / logs
> > > produced anywhere.
> > >
> > > # /opt/freeware/sbin/sssd -i -d4
> >
> > Are there also no messages if you run with -d 10 ?
> >
> 
> I just ran it and attached the output. It is showing lot of messges
> with "ldb" tag. Not sure how to interpret it.

Hmm, this is strange, for some reson the ldb library debug hooks work,
but not the sssd debugging itself? I don't know what to make of it
because both should be routed to the sss_vdebug_fn() function. I guess
it should be possible to gdb the monitor process and see what gets
called e.g. inside server_setup() when one of the DEBUG messages is
reached?

> 
> > On Linux, I would have said that strace with -ff would be also helpful,
> > but I have no idea if something like this exists on AIX.
> >
> 
> AIX strace seems to be different. But it has truss command which is
> similar to Linux strace. Just ran that as well. It provides
> good deal of info. Seems like i need to analyze the output to make out
> anything meaningful.
> 
> > >
> > > (1) root @ fvt-p7a2-lp16: /
> > >
> > > I see it invokes two other child process which also failed
> > > /opt/freeware/libexec/sssd/sssd_be --domain implicit_files --uid 0
> > > --gid 0 -d 0x01f0 --logger=stderr
> > > /opt/freeware/libexec/sssd/sssd_nss --uid 0 --gid 0 -d 0x01f0 
> > > --logger=stderr
> > >
> > > Any help would be appreciated.
> > >
> > > Thanks
> > > Ayappan P
> > > ___
> > > 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 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

> _poll(0x20057788, 4, 1928)  = 4
> _enrecvmsg(10, 0x2FF22358, 0, 0x)   = 1
> getpeereid(10, 0x2FF22380, 0x2FF2237C)  Err#76 ENOTCONN
> kread(10, " A U T H   E X T E R N A".., 2048)   = 18
> _poll(0x20057788, 4, 1926)  = 4
> _esend(10, 0x200575F8, 46, 256, 0x) Err#32 EPIPE
> Received signal #20, SIGCHLD [caught]

Here the child process (sssd_be) tries to connect to the sssd main
processes' D-Bus socket, sends the AUTH EXTERNAL command to try to
authenticate, but when the sssd tries to reply, the send
call returns EPIPE..this indicates the sssd_be process is exiting after
startup.

I can't tell from the truss output what makes the sssd_be fail. It would
be best to first figure out why the logger is not working..
___
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: sssd with sudo and non posix groups

[Jakub Hrozek]

On Wed, Nov 14, 2018 at 09:45:23AM -0800, Leonard Lawton wrote:
> On 11/14/2018 12:28 AM, Jakub Hrozek wrote:
> > On Tue, Nov 13, 2018 at 05:00:56PM -0800, Leonard Lawton wrote:
> > > I have a group in ldap(I'm using 389DS) called "_all" which has a
> > > groupofnames object class. Members are stored with the uniquemember
> > > attrtibute. The users in the group are able to login fine via ssh using 
> > > this
> > > setup. However, I can't seem to figure out how to get sudo(via ldap) to 
> > > work
> > > with my needs.
> > > The problem seems to be that I am using uniquemember which my 
> > > configuration
> > > is not interpreting. I can't use rfc2307 and fall back to posix groups(and
> > > memberUID) only as I rely heavily on the groupofnames's functionality, so 
> > > I
> > > really need to keep that. How can I configure sssd to let me use sudo 
> > > while
> > > having a groupofnames as an authoritative source?
> > Do the groups have a gidNumber? I assume not, otherwise you'd probably
> > create the groups with the posixGroup objectclass as well.
> They do have a gidNumber and have both posixGroup and groupofnames object
> classes.

Do they show up in the id output?

> > 
> > In general, I don't think sudo allows this, because sudo calls
> > getgrouplist(3) to see which groups the user belongs to and this call,
> > being POSIX only returns POSIX groups.
> > 
> > The schema (rfc2307 vs rfc2307bis) is not really relevant, what is
> > relevant is that the groups must be visible on the OS level, e.g. with
> > the id(1) call. I guess one way to go might be to create a POSIX group
> > (sudo_allowed) and add the _all group as a member of this sudo_allowed
> > group?
> The rfc2307 vs rfc2307bis comes into play as the group members have
> different attributes in posix vs groupofnames
> 
> Example membership of group _all when populating with posixGroup
> attritbutes:
> memberUid: bob

posixGroup does not imply memberUid, does it?

> 
> Example membership of group _all when populating with groupofnames
> attritbutes:
> uniqueMember: uid=bob,dc=something
> 
> sssd will never seem to allow memberUid /and/ uniqueMember to be searched as
> group membership.

yes, with ldap_schema=rfc2307bis, only 'member: $dn' is used by default by
SSSD. btw it looks like your configuration doesn't override the
ldap_group_member option, so I guess the uniqueMember attribute is not
used?

> > > Here is my config:
> > > 
> > > [domain/dingos]
> > > ldap_schema = rfc2307bis
> > > ldap_group_search_base = dc=dingos?sub?
> > > ldap_user_search_base = ou=people,dc=dingos
> > > ldap_uri = ldaps://ldap-server
> > > ldap_tls_cacertdir = /etc/openldap/cacerts
> > > sudo_provider = ldap
> > > ldap_access_filter = (|(memberof=cn=_all,ou=hosts,ou=roles,dc=dingos))
> > > id_provider = ldap
> > > auth_provider = ldap
> > > chpass_provider = ldap
> > > cache_credentials = false
> > > access_provider = ldap
> > > debug_level = 0x3ff0
> > > ldap_sudo_search_base = ou=SUDOers,ou=roles,dc=dingos
> > > entry_cache_timeout = 1
> > > 
> > > [sssd]
> > > config_file_version = 2
> > > services = nss, pam, sudo
> > > domains = dingos
> > > ___
> > > 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 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 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 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: Can I have sssd manage known_hosts with LDAP?

[Jakub Hrozek]

On Sat, Dec 08, 2018 at 08:09:09PM +0200, George Diamantopoulos wrote:
> User ssh public key retrieval works fine in my configuration. I'm using
> sssd 1.15 which ships with debian stretch.

I'm afraid the commit that exposed the host key lookup to the LDAP
provider is only present in 1.16.1 and newer.
___
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: filter out disabled ipa user

[Jakub Hrozek]

On Thu, Dec 06, 2018 at 10:59:04AM -, Stijn De Weirdt wrote:
> hi all,
> 
> we are using ipa as id_provider/access_provider/auth_provider for a domain, 
> and we want to somehow completely hide users that are disabled in ipa. for 
> now, disabled users are still known on the hosts (eg "getent passwd userxyz" 
> works and gives the correct userid). we would like that eg "getent passwd 
> userxyz" returns nothing (in particular we want that that userid can't start 
> any new process anymore, and that the nfs mounts show that files the belong 
> to the disabled user show up as owned by nobody etc etc.
> 
> is there any way to filter these users? perhaps some config setting  i 
> overlooked, or some ldap filter i can use?

If by disabled users you mean calling 'ipa user-disable' and e.g. not
locking our after login attempts, then I guess a variant of:

ldap_user_search_base = cn=accounts,dc=ipa,dc=test?sub?(nsaccountlock=false)

just using your search base might work.
___
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: sssd AD authentication working; sssd autofs against LDAP / rfc2307bis not working...

[Jakub Hrozek]

On Wed, Dec 05, 2018 at 12:28:18PM -0600, Spike White wrote:
> Sssd experts,
> 
> This is all on RHEL7.
> 
> I have sssd properly authenticating against AD for my multi-domain forest.
> All good – even cross-domain auth (as long as I don’t use tokengroups.)
> Our company’s AD implementation is RFC2307bis schema-extended.
> 
> Now – for complicated reasons – I’m told I need to get nis automaps and nis
> netgroups in AD and also working on the clients (via sssd) also.
> 
> As a first testing step, I’ve stood up an openLDAP server on another RHEL7
> server.  And schema extended it with RFC 2307 bis.
> 
> http://bubblesorted.raab.link/content/replace-nis-rfc2307-rfc2307bis-schema-openldap
> 
> I added an initial automap.
> 
> When I query via ldapsearch, all looks good:
> 
> [root@spikerealmd02 sssd]# ldapsearch -LLL -x -H ldap://
> austgcore17.us.example.com -b 'ou=automount,ou=admin,dc=itzgeek,dc=local'
> -s sub -D 'cn=ldapadm,dc=itzgeek,dc=local' -w ldppassword
> 'objectClass=automountMap'
> 
> dn: automountMapName=auto.master,ou=automount,ou=admin,dc=itzgeek,dc=local
> 
> objectClass: top
> 
> objectClass: automountMap
> 
> automountMapName: auto.master
> 
> 
> 
> dn: automountMapName=auto.home,ou=automount,ou=admin,dc=itzgeek,dc=local
> 
> objectClass: top
> 
> objectClass: automountMap
> 
> automountMapName: auto.home
> 
> 
> 
> [root@spikerealmd02 sssd]# ldapsearch -LLL -x -H ldap://
> austgcore17.us.example.com -b 'ou=automount,ou=admin,dc=itzgeek,dc=local'
> -s sub -D 'cn=ldapadm,dc=itzgeek,dc=local' -w ldppassword
> 'objectClass=automount'
> 
> dn:
> automountKey=/home2,automountMapName=auto.master,ou=automount,ou=admin,dc=
> 
>  itzgeek,dc=local
> 
> objectClass: top
> 
> objectClass: automount
> 
> automountKey: /home2
> 
> automountInformation:
> ldap:automountMapName=auto.home,ou=automount,ou=admin,dc
> 
>  =itzgeek,dc=local --timeout=60 --ghost
> 
> 
> 
> dn:
> automountKey=/,automountMapName=auto.home,ou=automount,ou=admin,dc=itzgeek
> 
>  ,dc=local
> 
> objectClass: top
> 
> objectClass: automount
> 
> automountKey: /
> 
> automountInformation:
> -fstype=nfs,rw,hard,intr,nodev,exec,nosuid,rsize=8192,ws
> 
>  ize=8192 austgcore17.us.example.com:/export/&
> 
> 
> 
> [root@spikerealmd02 sssd]#
> 
> 
> 
> Next, the sssd client configuration.
> 
> In my good sssd client’s sssd.conf file, I added “autofs” to my services
> line and added an “autofs” section.  That is,  I have changed my
> /etc/sssd/sssd.conf file as so:
> 
> [sssd]
> 
> …
> 
> services = nss,pam,autofs
> 
> …
> 
> [autofs]
> 
> debug_level = 9

All the options below should be specified in the domain section, not the
autofs section. The autofs responder only talks to the automounter
'client' (e.g. when you run automount -m), not to LDAP. The only process
in SSSD that ever talks to LDAP is sssd_be.

Running automount -m is also IMO a good way to test the config.

> 
> autofs_provider = ldap
> 
> ldap_uri= ldap://austgcore17.us.example.com
> 
> ldap_schema = rfc2307bis
> 
> ldap_default_bind_dn = cn=ldapadm,dc=itzgeek,dc=local
> 
> ldap_default_authtok = ldppassword
> 
> ldap_autofs_search_base = ou=automount,ou=admin,dc=itzgeek,dc=local
> 
> ldap_autofs_map_object_class = automountMap
> 
> ldap_autofs_map_name = automountMapName
> 
> ldap_autofs_entry_object_class = automount
> 
> ldap_autofs_entry_key = automountKey
> 
> ldap_autofs_entry_value = automountInformation
> 
> 
> 
> [nss]
> 
> debug_level = 9
> 
> 
> 
> I appended sss to automount line in /etc/nsswitch.conf file:
> 
> 
> 
> automount:  files sss
> 
> 
> 
> 
> 
> Yet, when I try to restart autofs service it (eventually) times out:
> 
> 
> 
>  [root@spikerealmd02 sssd]#  systemctl restart sssd
> 
> [root@spikerealmd02 sssd]# systemctl restart autofs
> 
> Job for autofs.service failed because a timeout was exceeded. See
> "systemctl status autofs.service" and "journalctl -xe" for details.
> 
> 
> 
> Journalctl –xe reports this:
> 
> 
> 
> Dec 03 11:14:09 spikerealmd02.us.example.com [sssd[ldap_child[9653]]][9653]:
> Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
> Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.

The domain log would tell you more, i.e. what principal did sssd_be try
to authenticate, but the tl;dr is that sssd_be couldn't authenticate to
the LDAP server.

> 
> …
> 
> Dec 03 11:14:15 spikerealmd02.us.example.com [sssd[ldap_child[9680]]][9680]:
> Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
> Preauthentication faile
> 
> Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: autofs.service
> start operation timed out. Terminating.
> 
> Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: Failed to start
> Automounts filesystems on demand.
> 
> -- Subject: Unit autofs.service has failed
> 
> -- Defined-By: systemd
> 
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> --
> 
> -- Unit autofs.service has failed.
> 
> --
> 
> -- The result is failed.
>

[SSSD-users] Re: Problem with resolving unqualified group names

[Jakub Hrozek]

On Fri, Nov 23, 2018 at 10:16:26AM +, Ondrej Valousek wrote:
> Hi List,
> 
> 
> I have noticed that in my case both
> 
> getent passwd @ and getent passwd 
> 
> works, but
> 
> getent group @
> 
> does not, only:
> 
> getent group 
> 
> works.
> 
> 
> Is that expected behavior?

No (but I don't know what else to add except worksforme..)
___
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: Can I have sssd manage known_hosts with LDAP?

[Jakub Hrozek]

On Mon, Dec 10, 2018 at 01:19:33PM -, George Diamantopoulos wrote:
> Thanks for the reply Jakub.
> 
> Does this mean that there is no support in 1.15 at all, or that the attribute 
> name is hardcoded as "fqdn" but still useable if the schema complies?

There is no support at all, the sss_ssh_knownhosts proxy has no
'handler' on the sssd_be side to talk to.
___
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: sssd database backup / restore (or transplant to another client)

[Jakub Hrozek]

On Thu, Jan 03, 2019 at 10:01:47AM +0200, Nikos Zaharioudakis wrote:
> Good morning list,
> 
> I have an idea, which I would like to experiment with, but experts
> advise may save me lots of time.
> 
> The scenario I have in mind is like this:
> 
> (assume OS and vers are latest RHEL/Centos)
> 
> I join a client to an IPA server. After joining, in the
> /var/lib/sss/db/ directory, a database per domain is expected. (or
> perhaps populated after the first request to the IPA server for
> example id some-username)
> 
> Now the question is:
> If I stop the sssd client service, may I copy the content of this
> directory to another client (which is already registered as well to
> the same IPA server) and save some time from the initial database
> population?
> You may say that this operation is not time-consuming etc, but in my
> case, I have to spin up some thousands of machines as fast as possible
> which are practically diskless. Meaning that the whole party has to
> happen as fast as possible and at the end, I have a ddos attack
> against my IPA servers and their replicas with a boom of (let's say)
> 3K clients asking more or less the same things (mostly ldap
> verification queries).

This is an interesting use-case we've seen a couple of times in diskless
clusters. We've also pondered the idea of 'priming' the cache, but AFAIK
so far nobody did this
> 
> So a first question to address my situation would be: Is the sssd db
> unique per client or may I "transplant" it to other clients as well?

Some parts of the database are unique to the client, especially in IPA
or AD cases, some can be copied.

If you install the ldb-tools package (in RHEL this is AFAIK in the
Optional channel), then you can inspect the cache with:
ldbsearch -H /var/lib/sss/db/cache_XXX
and:
ldbsearch -H /var/lib/sss/db/timestamps_

You'll see containers for users, groups, but also HBAC rules, ID
overrides and other data.

If you don't use ID overrides, then I guess it might be possible to
extract the user and group objects from the cache using ldbsearch and
add them to a 'new' cache with ldbadd/ldbmodify before starting the
node. It might be a good idea to also add the timestamps from the
timestamp cache to save the initial disk write. On the other hand, you
should not copy the whole cache as you might also copy HBAC rules meant
for another client. In theory this /should/ be OK as the HBAC rules are
refreshed on every access attempt (with a small timeout), but in case
the access was attempted offline, you could have run into the situation
where the cached rules meant for another client are evaluated.

btw the reason the timestamps are stored in a separate ldb file is that
the timestamp ldb file is opened in async mode, meaning a write does not
cause an fsync and the cache writes are buffered by the OS. This means
the cache writes are much faster, but in the odd case sssd crashed
before the buffers were flushed, the database might be inconsistent. So
we only use this fast mode for attributes that change often, like
timestamps, that change on every db write.

I think this is an interesting experiment, please let us know how it
goes.
___
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: sssd: AD service discovery and invalidating cache

[Jakub Hrozek]

On Fri, Jan 04, 2019 at 09:20:20AM +, R Davies wrote:
> (re-sending as I initially sent to ssd-users-owners in error)
> 
> For an AD environment using service discovery.
> 
> Periodically sssd will invalidate its cache at unexpected times.  Digging
> around debug logs and sources leads me to understand the following:
> 
> Every 15 minutes (or as defined by ldap_connection_expire_timeout) sssd
> re-establishes the connection to LDAP, closing the exiting collection.
> When sssd is configured to auto discover (via DNS _srv_ records, where the
> priority is the same for each server); auto-discovery might return a
> different LDAP server, at which point sssd's stored uSNChanged values are
> invalid (as these are unique to each server), the cached values are
> cleared, and enumeration is run - essentially afresh - against the new LDAP
> server.

Thank you very much for digging into the issue.

> 
> Is this outcome expected by design?

Honestly, I'm not sure and I would like some other developers to chime
in with their opinion.

Historically, we've said that SSSD should stick to a 'working' server as
long as it can, so on one hand I see the point in the sticky behaviour.
On the other hand, I've also seen admins relying on the TTL validity of
the SRV records, expecting that, if they change the SRV records, the
client chooses a new server after the TTL expires.

> 
> This behaviour is rather unfortunate as sssd_be will become CPU hog as it
> rebuilds the cache again.
> 
> It is possible to work around the behaviour e.g.:
> 
> 1) by not using service discovery, i.e.

Yes, in this case, the same server will always be selected from the
list, working around the problem.

> 
> ad_server = server1
> ad_backup = server2
> 
> which is fairly tiresome to maintain across an estate - separate
> configurations for different sites etc, faking load balancing by swapping
> configurations.
> 
> 2) having different priorities for each AD server in a given site, losing
> load balancing - unless DNS gave out different priorities depending on the
> source of the request, but this seems messy.
> 
> A better approach might be to patch sssd's auto discovery to "stick" to the
> previously bound LDAP server, currently the first server in the list of
> primary servers returned by ad_sort_servers_by_dns().  I have a proof of
> concept patch that is straight forward, and fairly well contained, the
> behaviour is controlled by an ad_sticky option in sssd.conf.
> 
> Is there a better solution to this problem?   Would a patch - as vaguely
> outlined above - likely gain acceptance?

If the behaviour is controllable by an option, my opinion is that it
would be a good approach.

Would the stickiness also persist across SRV priority levels? What I
mean is that if server1 had originally the highest priority (the lowest
priority value in the SRV record), but then the SRV record is expired
and the server is suddendly in a lower priority tier, IMO then the server
should be 'forgotten' and a new one chosen..
___
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: sssd: AD service discovery and invalidating cache

[Jakub Hrozek]

On Mon, Jan 07, 2019 at 06:01:08PM +, R Davies wrote:
> On Fri, 4 Jan 2019 at 10:19, Jakub Hrozek  wrote:
> 
> > Would the stickiness also persist across SRV priority levels? What I
> > mean is that if server1 had originally the highest priority (the lowest
> > priority value in the SRV record), but then the SRV record is expired
> > and the server is suddendly in a lower priority tier, IMO then the server
> > should be 'forgotten' and a new one chosen..
> >
> 
> You're right to highlight this.  Different admins may have different
> requirements,  perhaps the configuration option "ad_sticky" could control
> behaviour:
> 
> always - Always sticky, prefer the originally discovered server, unless the
> sticky server has been removed from the service record
> priority - Mostly sticky, prefer the originally discovered server, unless
> its priority in the service record has changed
> never - No stickiness (default, and current behaviour), i.e. always
> potentially change ldap server on expiry of the ldap connection.

As long as the default behaviour stays the same, I'm fine with just
implementing never and always or never and priority. I think it's just
important not to prevent extending the code further.

> 
> In terms of implementation, would this be confined to the AD provider or
> would IPA also benefit with this?  If so, the perhaps it should live
> in fail_over_srv.c.  I'm a bit unclear as to how this might be implemented
> in the fail_over_srv "plugin".  The fo_discover_srv_* functions have a
> resolv_ctx available to them, but it would seem neater to have a dedicated
> fo_discover_ctx structure to store the configuration, along with the sticky
> ldap server name.

My initial idea was to create a wrapper around resolv_sort_srv_reply()
that would take the previous server and optionally a flag parameter.

Then, if the previous server was present and the flags would indicate
that the server should be preferred, it would just be moved to the 1st
place in the list. The previous server would probably have to be kept
somewhere in the fail over code, maybe struct fo_ctx could be used?

If course, fo_discover_ctx could also be used, did you think about
creating it as a member of fo_ctx, maybe created during
fo_set_srv_lookup_plugin() ?
___
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: Sudo in a ldap

[Jakub Hrozek]

On Mon, Jan 14, 2019 at 09:06:31AM +0100, Maupertuis Philippe wrote:
> Hi,
> I am new on this mailing list so please forgive me if my question has already 
> been answered.
> I did read the archive to try find something.
> 
> My d.conf retrieve the information from a 389ds ldap including sudo rules.
> Everything is working fine except for one point regarding sudo.
> For a given user only one entry  is fetched from the ldap.
> Is it working as intended ?
> What I would like to achieve is basically something as simple as :
> User => root  :some commands
> User  => mysql : ALL
> This is easily done with a local sudoers, but I failed to have it working 
> with sssd and the ldap.

This is a good starting point regarding sudo troubleshooting:
https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html

Posting the rules LDIF might be a good idea as well.
___
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: Understanding sssd cache

[Jakub Hrozek]

On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote:
> 
> 
> > -Message d'origine-
> > De : Lukas Slebodnik [mailto:lsleb...@redhat.com]
> > Envoyé : mercredi 16 janvier 2019 12:47
> > À : End-user discussions about the System Security Services Daemon
> > Objet : [SSSD-users] Re: Understanding sssd cache
> >
> > On (16/01/19 09:14), Maupertuis Philippe wrote:
> > >Hi
> > >I am trying to find out how th sssd cache is being populated.
> > >I couldn't find much about it so I did some tests.
> > >It seems that with enumerate = true, the cache holds all the information
> > needed as soon as sssd is started.
> > >With enumerate = false, the cache holds information about someone only
> > after his first connection.
> > >Is that right ?
> > >I would like to be sure that user's passwords are stored in the cache but
> > couldn't find any way to verify this
> > >With sssctl user-show  I can find if a user is in the cache but with no 
> > >details.
> > >With sssctl user-checks I get some information about the user but nothing
> > about the password.
> > >By examining directly the cache with ldbsearch I don't find any password
> > information either, only maybe shadowLastChange: with a number which I
> > don't understand.
> > >Is there any documentation about the cache management ?
> > >
> >
> > Hashed password is cached only after successful authentication. It is not
> > rerieved by "getent passwd $user".
> >
> > sssd cache is internal cache and should not be used directly by user.
> I understand that and was looking at it only to try to understand how it 
> works.
> 
> > May I know what do you want to achieve?
> When using regular ssh access the the ssh publickey is in the cache if needed.
> A user who had not connected previously is able to connect even if the 
> backend is unreachable
> When using the console, we have to rely on the password.
> When something goes wrong (sshd down or network issue), there is a high 
> probability that the user would connect to the console for the first time.
> So if there is no guarantee the login could be successful offline we need to 
> have a local  (shared) account to connect to the console.
> A shared account is a nightmare to manage and a sore point for audits, we 
> would like to remove it.

The sss_seed tool was meant as a way to mitigate this.
___
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: Understanding sssd cache

[Jakub Hrozek]

On Wed, Jan 16, 2019 at 03:50:59PM +0100, Maupertuis Philippe wrote:
> 
> 
> > -Message d'origine-----
> > De : Jakub Hrozek [mailto:jhro...@redhat.com]
> > Envoyé : mercredi 16 janvier 2019 15:24
> > À : sssd-users@lists.fedorahosted.org
> > Objet : [SSSD-users] Re: Understanding sssd cache
> >
> > On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote:
> > >
> > >
> > > > -Message d'origine-
> > > > De : Lukas Slebodnik [mailto:lsleb...@redhat.com]
> > > > Envoyé : mercredi 16 janvier 2019 12:47
> > > > À : End-user discussions about the System Security Services Daemon
> > > > Objet : [SSSD-users] Re: Understanding sssd cache
> > > >
> > > > On (16/01/19 09:14), Maupertuis Philippe wrote:
> > > > >Hi
> > > > >I am trying to find out how th sssd cache is being populated.
> > > > >I couldn't find much about it so I did some tests.
> > > > >It seems that with enumerate = true, the cache holds all the 
> > > > >information
> > > > needed as soon as sssd is started.
> > > > >With enumerate = false, the cache holds information about someone
> > only
> > > > after his first connection.
> > > > >Is that right ?
> > > > >I would like to be sure that user's passwords are stored in the cache 
> > > > >but
> > > > couldn't find any way to verify this
> > > > >With sssctl user-show  I can find if a user is in the cache but with no
> > details.
> > > > >With sssctl user-checks I get some information about the user but
> > nothing
> > > > about the password.
> > > > >By examining directly the cache with ldbsearch I don't find any 
> > > > >password
> > > > information either, only maybe shadowLastChange: with a number which
> > I
> > > > don't understand.
> > > > >Is there any documentation about the cache management ?
> > > > >
> > > >
> > > > Hashed password is cached only after successful authentication. It is 
> > > > not
> > > > rerieved by "getent passwd $user".
> > > >
> > > > sssd cache is internal cache and should not be used directly by user.
> > > I understand that and was looking at it only to try to understand how it
> > works.
> > >
> > > > May I know what do you want to achieve?
> > > When using regular ssh access the the ssh publickey is in the cache if
> > needed.
> > > A user who had not connected previously is able to connect even if the
> > backend is unreachable
> > > When using the console, we have to rely on the password.
> > > When something goes wrong (sshd down or network issue), there is a high
> > probability that the user would connect to the console for the first time.
> > > So if there is no guarantee the login could be successful offline we need 
> > > to
> > have a local  (shared) account to connect to the console.
> > > A shared account is a nightmare to manage and a sore point for audits, we
> > would like to remove it.
> >
> > The sss_seed tool was meant as a way to mitigate this.
> If I understand it correctly to have only nominative account in place for 
> console login, each user would have to put his own password in the cache 
> before something goes wrong.
> Obviously it won't work in a large environment.
> So we can't rely on SSSD and its cache for console login, a local user is 
> mandatory.

If you're going to orchestrate useradd for each local user, how is that
more difficult than sss_seed for each remote user?
___
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

Re: [SSSD-users] Authentication failure

[Jakub Hrozek]

On Sat, Aug 25, 2012 at 1:01 AM, Chris Hartman  wrote:
> Hi all,
>
> Arch: i386
> OS: Fedora 17
>
> Using the compiled source from the git repo, I'm having trouble getting
> users to authenticate via PAM with the pam_sss.so module.
>
> I can do ID lookups, enumerate user information, and "pam_test_client"
> returns successful for all cases, but when logging in via SSH or through the
> TTY, I get authentication failure. As an already-authenticated local user,
> su commands/password auth work.
>
> This problem persists despite pam_sss.so's order in the stack or its
> control. Examining the logs, I don't see any error messages from pam_sss.

Hi Chris,

Do you see pam_sss being contacted at all? If so, are there any log
messages in /var/log/sss/sssd_pam.log (provided you set debug_level to
the [pam] section) ?

> When installed from the repos, SSSD performs as expected.
>

What was the version that worked for you from the repos? I suspect
SELinux might be causing trouble, because the 1.9 pre-release you
checked out from git contains a number of features that needed
tweaking the SELinux policy. Make sure you are running at least
selinux-policy-3.10.0-146 if you are running in the Enforcing mode.
This version is currently in updates-testing for F17, see:
https://admin.fedoraproject.org/updates/FEDORA-2012-12355

> I'd like to contribute to the project but thought it'd be a good idea to get
> a system up and running with the unaltered source, first. Thanks.
>

Sure, having a working baseline is important.

The SSSD wiki contains a number of tips tutorials that might be helpful:
https://fedorahosted.org/sssd/wiki/DevelTips
https://fedorahosted.org/sssd/wiki/DevelTutorials

Thank you for your interest in the SSSD!
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd ldap bind timeout

[Jakub Hrozek]

On Mon, Aug 27, 2012 at 11:39:24AM +0200, Olaf Gellert wrote:
> Hi there,
> 
> we do see some timeouts when sssd tries to bind to the LDAP
> server:
> 
> (Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [be_resolve_server_done]
> (4): Found address for server xxx1.domain.de: [10.11.12.13] TTL 21600
> (Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [fo_set_port_status] (4):
> Marking port 636 of server 'xxx1.domain.de' as 'working'
> (Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [set_server_common_status]
> (4): Marking server 'xxx1.domain.de' as 'working'
> (Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [simple_bind_send] (4):
> Executing simple bind as: uid=abcdefg,ou=People,o=ldap,o=root
> (Mon Aug 27 10:35:59 2012) [sssd[be[LDAP]]] [be_run_offline_cb] (3):
> Going offline. Running callbacks.
> (Mon Aug 27 10:35:59 2012) [sssd[be[LDAP]]] [be_pam_handler_callback]
> (4): Backend returned: (1, 9, ) [Provider is Offline
> (Authentication service cannot retrieve authentication info)]
> 
> In this case sssd seems to not ask the second ldap server?
> We ser the "ldap_search_timeout" option to 120 seconds (default
> is 6 seconds), but this does change the behaviour.
> 
> We are running sssd 1.5.1 (as distributed with CentOS 5.X).
> 
> Looking at all the different ldap timeout values, I guess that
> "ldap_network_timeout" is not the right thing (because network
> connect does work), could "ldap_opt_timeout" provide some solution
> (as I do not really understand what it does)?
> 
> Cheers, Olaf

Hi Olaf,

as you discovered, the ldap bind timeout is currently hardcoded to 5
seconds. I think we wanted to make this setting configurable when we
were working on making the bind asychronous, but we cancelled that
effort.

Maybe it would be beneficial to either reuse ldap_opt_timeout for the
bind timeout value or introduce a new timeout. I filed
https://fedorahosted.org/sssd/ticket/1501 to track this.

I am far more concerned about the provider going offline without asking the
secondary LDAP server. I'll try to reproduce the issue locally.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd ldap bind timeout

[Jakub Hrozek]

On Thu, Aug 30, 2012 at 08:33:51AM +0200, Olaf Gellert wrote:
> Hi Jakub,
> 
> thanks for your answer.
> 
> Jakub Hrozek wrote:
> > Maybe it would be beneficial to either reuse ldap_opt_timeout for the
> > bind timeout value or introduce a new timeout. I filed
> > https://fedorahosted.org/sssd/ticket/1501 to track this.
> 
> thanks.
> 
> > I am far more concerned about the provider going offline without asking the
> > secondary LDAP server. I'll try to reproduce the issue locally.
> 
> If I can help you with anything, just say what you need.
> 

Hi Olaf,

I think I may have found your problem. In the extremely rare case when
the initial connection to the LDAP server would succeed but then the
bind request would time out, the SSSD would not retry the next server.

If you tell me the exact version you are running (the whole output of rpm
-q sssd), I can prepare a scratch build for you to test if my patch fixes
your issue.

However, I'm curious about how you could end up in a situation like
this. Can you run the following test for me?

ldapsearch -x -H ldap://xxx1.domain.de  \
   -D "uid=abcdefg,ou=People,o=ldap,o=root" \
   -w "thepassword" \
   -b uid=abcdefg,ou=People,o=ldap,o=root
   -s base

I used the sanitized values you used in the original report, substitute
them for the real ones you use, please and also use -Z or similar
depending on your real configuration. The above command should trigger
a similar codepath using libldap API as the SSSD does. Does it succeed
in your environment? Are there maybe any interesting messages in the
server log?
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Encoded Packet Size Too Big

[Jakub Hrozek]

On Tue, Sep 04, 2012 at 04:00:57PM +, Wojtak, Greg (Superfly) wrote:
> Every once in a while with SSSD, we run into a problem where we aren't able 
> to get user information or authenticate users.  We are using ldap/kerberos 
> against an Active Directory set up over SSL (LDAPS) and we see the following 
> message in the logs:
> 
> encoded packet size too big (813957100 > 16777215)
> 

Hi Greg,

are you using ldap:// or ldaps:// schema to connect to the AD server?

If you are getting the same error with ldapsearch & friends, then the
issue is not inside SSSD. This error happens when the AD issues a PAC
that is too big for the SASL library to handle -- the PAC contains
information about users and groups as well and might grow in a very
large organization.

> From what I've been able to gather, this is something to do with the 
> cyrus-sasl package.  I've also seen this error pop up when doing operations 
> with the openldap-clients (ldapsearch, ldapmodify).  I've found that by 
> specifying the minssf and maxssf values in the ldap* operations that the 
> operations would then succeed.
> 
> I'm wondering if the same type of fix would work for SSSD?  Is there a way to 
> specify the SSF of the SASL operations that SSSD uses?  Is there another 
> workaround for this?
> 

You can use the ldap_sasl_minssf option to fine-tune the SSF. The code
path that uses the option value is the same as openldap-clients
utilities use, so if you were able to find a value that works for you
with ldapsearch, then the same should work with the SSSD, too.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Encoded Packet Size Too Big

[Jakub Hrozek]

On Tue, Sep 04, 2012 at 05:50:08PM +, Wojtak, Greg (Superfly) wrote:
> I am not specifying a schema but verified that sssd is using ldaps:// -
> tcpdump and netstat show connections to my DC's on port 636 and none on
> 389.
> 

Interesting, what is the exact format of ldap_uri you are using in the
sssd.conf config file?

Are you using GSSAPI? (ldap_sasl_mech = GSSAPI in the config file)
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Encoded Packet Size Too Big

[Jakub Hrozek]

On Tue, Sep 04, 2012 at 06:57:48PM +, Wojtak, Greg (Superfly) wrote:
> On 2012-09-04 2:03 PM, "Jakub Hrozek"  wrote:
> 
> 
> >On Tue, Sep 04, 2012 at 05:50:08PM +, Wojtak, Greg (Superfly) wrote:
> >> I am not specifying a schema but verified that sssd is using ldaps:// -
> >> tcpdump and netstat show connections to my DC's on port 636 and none on
> >> 389.
> >> 
> >
> >Interesting, what is the exact format of ldap_uri you are using in the
> >sssd.conf config file?
> >
> >Are you using GSSAPI? (ldap_sasl_mech = GSSAPI in the config file)
> 
> 
> I should have been more clear - I should have said I'm not specifying
> ldap_uri at all (service discovery?) and yes, I have ldap_sasl_mech =
> GSSAPI set.
> 

Can you try if using ldap:// instead of ldaps:// perhaps using the
ldapsearch command line tool works for you?
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] Announcing SSSD 1.9.0 beta 7

[Jakub Hrozek]

= Detailed Changelog ==

Ariel Barria (1):
  * SIGUSR2 should force SSSD to reread resolv.conf as well

Jakub Hrozek (32):
  * Bumping version for the 1.9.0 release
  * Don't call fo_set_{server,port}_status for SRV servers
  * Fix the version number
  * SYSDB: Check the return value
  * SYSDB: Use ldb_msg_add_string for simple string additions
  * Failover: Return last tried server if it's still being tried
  * Subdomains: Send the DP reply in the correct format
  * Always mark SRV servers as primary
  * Allocate on top of a talloc context, not NULL
  * Abort PAM access phase if HBAC does not return PAM_SUCCESS
  * Change default for ldap_idmap_range_min to 20
  * Don't use server after SRV data collapsed
  * Document entry_cache_autofs_timeout
  * Add autofs-related options to configAPI
  * sss_client: Group lookups should work even when fastcache cannot be 
initialized
  * FO: Don't retry the same server if it's not working
  * FO: Return EAGAIN if there are more servers to try
  * KRB5: Only return PAM error for unreachable kpasswd when performing 
chpass
  * Build SELinux code in responder conditionally
  * Do not try to remove the temp login file if already renamed
  * Only create the SELinux login file if there are mappings on the server
  * Fix compilation error in Python murmurhash bindings
  * Process all groups from a single nesting level
  * Use PTHREAD_MUTEX_ROBUST to avoid deadlock in the client
  * RPM: Switch the default ccache location
  * RPM: Always include the patch file
  * Check if the SELinux login directory exists
  * SYSDB: Commit transaction in sysdb_store_user
  * SYSDB: Abort unit test if sysdb_getpwnam fails
  * Retry the next server if bind during LDAP auth times out
  * Don't terminate the same connection twice
  * Update translations for 1.9.0 beta 7 release

Jan Cholasta (3):
  * SSH: Return error code in SSH utility functions
  * SSH: Simplify public key formatting function
  * SSH: Add support for OpenSSH-style public keys

Michal Zidek (10):
  * Return value of fread in src/tools/sss_debuglevel.c no longer ignored.
  * Change default value of ldap_sasl_string to host/hostname@REALM in man 
page.
  * SRV resolution for backup servers should not be permitted.
  * When ldap_group_nesting_level was reached, the LDAP provider tried to 
link group members with groups outside nesting limit.
  * Duplicate detection in fail over did not work.
  * Typo in debug message (SSSd -> SSSD).
  * Unify usage of sysdb transactions
  * Fix: IPv6 address with square brackets doesn't work.
  * Adding -std=gnu99 flag.
  * Unify usage of sysdb transactions (part 2).

Nick Guay (1):
  * remove duplicate sss_obfuscate reference in seealso manpage section

Ondrej Kos (5):
  * Removed unused variable assignment
  * Replaced "id_max" & "id_min"
  * Backward GOTOs rewritten into do-while loops.
  * AD context was set to null due to type mismatch
  * Consolidation of functions that make realm upper-case

Pavel Březina (12):
  * tests: build sysdb ssh tests conditionally
  * shadow attributes can contain -1
  * Add end of line to debug message
  * monitor: set debug level when unable to load configuration
  * Remove redefinition of some SYSDB_* macros
  * Rename SYSDB_SUDO_CACHE_AT_OC to SYSDB_SUDO_CACHE_OC
  * Remove SYSDB_SUDO_CACHE_OC from attribute lists
  * Fix LOCAL domain lookups
  * Close LDAP connection when unable to install TLS
  * Unbreak build on RHEL5: replace ldap_destroy() with ldap_unbind_ext()
  * Remove compilation warning: ret may be uninitialized
  * Clean up cache on server reinitialization

Stephen Gallagher (6):
  * SSSDConfig: Fix nonfunctional SSSDDomain.remove_provider()
  * IPA: Do not attempt to close the same file twice
  * IPA: Securely set umask for mkstemp in subdomain provider
  * MAN: Fix minor typo in ldap_search_base section
  * MAN: Improve description of ldap_*_search_base options
  * SYSDB: Make sysdb_attrs_get_el_int() public

Sumit Bose (5):
  * Add python bindings for murmurhash3
  * accept_fd_handler: add missing return
  * Fix fallback in validate_tgt()
  * Use new debug levels in validate_tgt()
  * Check flat names when searching for sub-domains as well

Yuri Chornoivan (1):
  * Fix various typos in documentation.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] pam_sss returns PAM_SYSTEM_ERR when entering wrong Kerberos password

[Jakub Hrozek]

On Fri, Sep 07, 2012 at 05:44:59PM +0200, Joschi Brauchle wrote:
> Hello,
> 
> I noticed a problem when using pam_sss (1.8.3) under OpenSUSE 12.2 +
> KDE and filed a bugreport there:
> https://bugzilla.novell.com/show_bug.cgi?id=779246
> 
> When a Kerberos user enters a wrong password, a KDM "Critical error"
> message pops up (see link above for a screenshot).
> 
> In /var/log/messages, there is
> --
> Sep  7 11:34:03 test-os122 [sssd[krb5_child[1102]]]: Decrypt integrity check
> failed
> Sep  7 11:34:03 test-os122 [sssd[krb5_child[1102]]]: Decrypt integrity check
> failed
> Sep  7 11:34:03 test-os122 kdm: :0[1085]: pam_sss(xdm:auth): system info:
> [Decrypt integrity check failed]
> Sep  7 11:34:03 test-os122 kdm: :0[1085]: pam_sss(xdm:auth): authentication
> failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=testuser
> Sep  7 11:34:03 test-os122 kdm: :0[1085]: pam_sss(xdm:auth):
> received for user
> testuser: 4 (System error)
> --
> 
> As far as I know, "decrypt integrity fails" is the default Kerberos
> error message for a wrong password. Hence, this is not a "System
> error", but rather an authentication error.
> 
> When looking at the code of "krb5_child.c", it seems like the
> default return code when checking the Kerberos TGT is
> "PAM_SYSTEM_ERR", which also gets returned in the event of a simply
> wrong password.
> 
> I guess, pam_sss should instead return "PAM_AUTH_ERR", is that correct?
> Has this been fixed in versions > 1.8.3?
> 

You are absolutely correct, nice catch Joschi.

It has not been fixed so, far, I have filed
https://fedorahosted.org/sssd/ticket/1515 to track this
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] pam_sss returns PAM_SYSTEM_ERR when entering wrong Kerberos password

[Jakub Hrozek]

On Sun, Sep 09, 2012 at 04:11:07PM +0200, Joschi Brauchle wrote:
> Hello Jakub,
> 
> I have prepared a patch (see Novell bugzilla) that adds a check for
> the "Decrypt integrity check failed" Kerberos error code to the
> switch statement, which then returns PAM_AUTH_ERR.
> 
> I tested that patch with OpenSUSE12.2 + KDM as well as SSH password
> based login and can confirm that the misleading error message goes
> away (for SSH there was only a misleading syslog error but not for
> the user).
> 
> However, the mentioned patch only changes the PAM return code when
> using Kerberos with a password. I am not sure if there may be other
> spots in the krb5_child that may also need fixing, as there are
> other possibilities to use Kerberos auth (forwarded TGT, keytab, and
> so on).
> 
> Best regards,
> Joschi Brauchle
> 

Yep, my patch added the same handler as your did, just inside a new
function that is also reused during password change.

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

Re: [SSSD-users] sss_cache not working?

[Jakub Hrozek]

On Mon, Sep 10, 2012 at 04:21:51PM +0200, Ondrej Valousek wrote:
> Hi List,
> 
> I wanted to use sss_cache to find out whether sssd is running in a
> connected or disconnected mode, but I found out it is not working
> the way I expected.
> Example:
> 
> 1.
> # id -a ondrej
> - shows something about me.
> 2.
> # sss_cache -u ondrej
> - I expect all information about me is trashed

No, the information is never completely removed. It is only marked as
expired so that the next lookup would go to the server and download
fresh data again.

> 3.
> # id -a ondrej
> - still shows information about me even if no ldap provider is available to 
> connect. Evidently sssd still returns cached information.
> 
> Is this a normal behavior or is this a bug?
> Thanks,
> 

A proper test would look like:
1. id -a ondrej
2. change an attribute of ondre's record
3. sss_cache -u ondrej
4. id -a ondrej

Step 4. should print updated information on ondrej.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Kerberos principal > canonicalization is not available!

[Jakub Hrozek]

On Mon, Sep 10, 2012 at 10:44:18AM -0700, John Thomas wrote:
> 
> I just figured it out.  The problem was in my /etc/krb5.  My encryption types 
> listed are as follows:
> 
> default_tgs_enctypes = aes256-cts rc4-hmac des-cbc-crc des-cdc-md5
> default_tkt_enctypes = aes256-cts rc4-hmac des-cbc-crc des-cdc-md5
> permitted_enctypes = aes256-cts rc4-hmac des-cbc-crc des-cbc-md5
> 
> However my keytab did not have entries for aes256-cts.  So I removed these 
> entries for each of the above parameters, and it worked.
> 

I'm glad you were able to fix the problem and thank you for letting us
know the solution, it might be very helpful for other users.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] Announcing SSSD 1.9.0 RC1

[Jakub Hrozek]

== Highlights ==
The SSSD team is proud to announce a Release Candidate of version 1.9 of
the System Security Services Daemon.

This is a bugfix release only, no new features were added in this version.
We will be focusing on more stabilizing after that point until the final
1.9.0 release which is tentatively scheduled for September 21. We might
be releasing another Release Candidate before the final release if needed.

As always, you can download the latest sources at
https://fedorahosted.org/sssd/

== Tickets Fixed ==

https://fedorahosted.org/sssd/ticket/1331
Off-by-one error in sss_hmac_sha1
https://fedorahosted.org/sssd/ticket/1364
[abrt] sssd-1.8.3-11.fc16: set_server_common_status: Process 
/usr/libexec/sssd/sssd_be was killed by signal 11 (SIGSEGV)
https://fedorahosted.org/sssd/ticket/1438
SSSD crashes at boot time
https://fedorahosted.org/sssd/ticket/1452
Authentication fails if kpasswd cannot be resolved
https://fedorahosted.org/sssd/ticket/1454
if allocation fails, sss_mmap_cache_init may dereference NULL pointer
https://fedorahosted.org/sssd/ticket/1458
Full sudo refresh is scheduled even if there is no sudo responder
https://fedorahosted.org/sssd/ticket/1466
Proxy: Cannot retrieve an user after a group he is a member of was retrieved
https://fedorahosted.org/sssd/ticket/1467
enumeration is broken in the proxy provider
https://fedorahosted.org/sssd/ticket/1479
Hbac logs show wrong rule name granting access
https://fedorahosted.org/sssd/ticket/1486
[abrt] sssd-1.8.4-14.fc17: sss_ldap_init_send: Process 
/usr/libexec/sssd/sssd_be was killed by signal 11 (SIGSEGV)
https://fedorahosted.org/sssd/ticket/1496
[abrt] sssd-1.8.4-14.fc17: ldap_pvt_sasl_getmechs: Process 
/usr/libexec/sssd/sssd_be was killed by signal 11 (SIGSEGV)
https://fedorahosted.org/sssd/ticket/1505
sudo with sss backend should use ipa_hostname
https://fedorahosted.org/sssd/ticket/1509
libsss_sudo is not updated when yum update sssd is called
https://fedorahosted.org/sssd/ticket/1513
Change the processing of the SELinux default map
https://fedorahosted.org/sssd/ticket/1515
pam_sss report System Error on wrong password
https://fedorahosted.org/sssd/ticket/1516
krb5_mod_ccname should cancel the transaction at one place only
https://fedorahosted.org/sssd/ticket/1519
membership of IPA hostgroups is not evaluated when treating them as 
netgroups

== Detailed Changelog ==

Jakub Hrozek (12):
* Bumping version for the 1.9.0 beta 7 release
* libsss_sudo should have a versioned dependency on SSSD
* KRB5: cancel the sysdb transaction on one place only
* KRB5: Return PAM_AUTH_ERR on incorrect password
* RPM: BuildRequire? selinux-policy-targeted
* SYSDB: NULL-terminate the output of sysdb_get_{ranges,subdomains}
* KRB5: Add a missing string argument
* NSS: Fix off-by-one error in parse_getservbyname
* FO: Check server validity before setting status
* DB: Always write the SELinux object to sysdb
* SELinux: Always use the default if it exists on the server
* Updating the translations for the 1.9.0 RC1 release 

Ondrej Kos (1):
* Out-of-bounds read fix in hmac-sha-1 

Pavel Březina (3):
* netgroup: resolve hostgroup membership correctly
* be_process_init(): free ctx on error
* backend: initialize sudo only when it is enabled in services 

Simo Sorce (1):
* Remove obsolete comment 
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] [SOLVED] cannot authenticate one user

[Jakub Hrozek]

On Mon, Sep 17, 2012 at 05:24:16PM -0400, Dmitri Pal wrote:
> On 09/17/2012 05:12 PM, Michael Cronenworth wrote:
> > Dmitri Pal wrote:
> >> debug_level=9
> >> /var/log/sssd/sssd_default.log
> > Thanks.
> >
> >> sssd.conf and krb5.conf would be helpful too.
> > The F16 (not working) and F17 (working) boxes have identical sssd.conf
> > and krb5.conf files. Verified by diff. The boxes are also using the same
> > DNS server (runs on the F16 box) with the exact same /etc/resolv.conf
> > file. I have attached the files for completeness.
> >
> > The problem? The machine's FQDN was not set. Even though
> > /etc/sysconfig/network has it set, the "hostname -f" command did not
> > return the full domain name. The SRV requests SSSD was trying to perform
> > were against the machine name instead of the domain name. Setting the
> > FQDN got things working again. No conf file changes were required. I'm
> > not sure how the hostname got changed as this was working properly in
> > the past.
> 
> I am glad things worked out for you.

You can also set the dns_discovery_domain to explicitly specify the
discovery domain the SSSD should be using.

In the absence of that parameter, the SSSD uses the domain part of the
host name.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] [SOLVED] cannot authenticate one user

[Jakub Hrozek]

On Wed, Sep 19, 2012 at 08:35:21AM -0500, Michael Cronenworth wrote:
> Ondrej Valousek wrote:
> > nope.
> > You need to use tool AD sites and services to create AD site first (you
> > should have done that anyway if you have AD controllers behind a slow
> > VPN link).
> 
> OK, thanks. I am not an AD expert (nor the admin of the Windows network)
> so I did not understand what you meant. I got the site name and tried:
> 
> dns_discovery_domain = Sitename._sites.example.com
> 
> The LDAP and KERBEROS services detected the correct server name, but the
> KPASSWD service was "not found" so my system could not authenticate me.

For the record, the fact that the back end went offline if the kpasswd
server could not be resolved is a bug we fixed during the 1.9 development:
https://fedorahosted.org/sssd/ticket/1452
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd with AD/krb5 authentication and non-standard userPrincipalName

[Jakub Hrozek]

On Wed, Sep 26, 2012 at 07:37:50PM +, Rosile, Mike wrote:
> I have somewhat of a unique situation which causes the userPrincipalName 
> value in Active Directory to use a public DNS domain as its realm, but the 
> Active Directory was designed with a private DNS domain.
> 
> For example, user John Smith would typically be 
> jsmith@example.local but his userPrincipalName 
> is jsm...@example.com.
> 
> Unfortunately when trying to authenticate with pam_sss, the "krb5" child 
> process will complain that the KDC is not local to the realm.  The KDC might 
> be something like kdc.example.local, and in this instance the realm is 
> EXAMPLE.COM.  Same situation if I try to `kinit 
> jsm...@example.com`, the error about the KDC 
> not being local to Realm occurs.
> 
> Is there some other way that sssd could construct the userPrincipalName 
> instead of me trying to create and populate a custom AD attribute?
> --
> Mike
> 

Would user@REALM (where REALM is the krb5_realm option value) be the
correct principal for you?

If so, then there is a simple workaround that Stephen Gallagher came up with --
you could set the ldap_user_principal config option to some attribute
that does not exist which would make the SSSD default to user@REALM..

Your situation is not as unique as you might think, this is actually the
second similar feature request we've gotten this week. I think we should
think about introducing a new option:
https://fedorahosted.org/sssd/ticket/1545
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] [SSSD] Announcing SSSD 1.9.1

[Jakub Hrozek]

  === SSSD 1.9.1 ===

The SSSD team is proud to announce the release of version 1.9.1 of
the System Security Services Daemon.

As always, the source is available from https://fedorahosted.org/sssd

RPM packages will be made available for Fedora shortly, initially for F-18
and rawhide and later also backported to F-17.

== Feedback ==

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

== Highlights ==

 * The distribution tarball was fixed to include a missing file, which
   prevented "make rpms" from running correctly.
 * Handle gracefully the situation where the namingContext is zero-length,
   such as when connected to the Novell eDirectory server.
 * A new option default_domain_suffix was added. This option is mainly
   useful for environments whose users come from a trusted domain so that
   the user doesn't have to specify that trusted domain with every user lookup.
 * Many man page fixes that were held from the 1.9.0 release during the
   string freeze
 * The entries in the generated known_hosts file are now expired preventing
   the file from growing indefinitely
 * The PID file is now created after all the SSSD services start up to
   avoid notifying the user via the init system before SSSD is able to
   handle requests.

== Tickets Fixed ==

https://fedorahosted.org/sssd/ticket/1303
SSSD is slow at startup
https://fedorahosted.org/sssd/ticket/1357
Init script reports complete before sssd is actually working
https://fedorahosted.org/sssd/ticket/1471
Range Retrieval: Unable to retrieve all members when filter is used
in search base.
https://fedorahosted.org/sssd/ticket/1483
Mention ldap_schema types on newlines or comma separate them.
https://fedorahosted.org/sssd/ticket/1494
ldap_chpass_update_last_change is not included in the manual page
https://fedorahosted.org/sssd/ticket/1525
Explain default re_expression in IPA and AD provider man pages
https://fedorahosted.org/sssd/ticket/1529
[RFE] Login with users from a trusted domain always requires a FQ name
https://fedorahosted.org/sssd/ticket/1533
Improve recreating new ccache file when the old one is not accessible
any more
https://fedorahosted.org/sssd/ticket/1535
Flip the default value of ldap_initgroups_use_matching_rule_in_chain
https://fedorahosted.org/sssd/ticket/1537
Fix sssd-ad id ranges
https://fedorahosted.org/sssd/ticket/1540
[man sssd-ldap] 'ldap_access_filter' description needs to be updated
https://fedorahosted.org/sssd/ticket/1541
Manpage has ldap_autofs_search_base as experimental feature
https://fedorahosted.org/sssd/ticket/1542
User authentication using LDAP doesn't work
https://fedorahosted.org/sssd/ticket/1546
sss_seed "-h" and "--help" options should output similar results
https://fedorahosted.org/sssd/ticket/1548
User authentication fails when password is read from a file using -p
option of SSS_SEED tool.
https://fedorahosted.org/sssd/ticket/1549
Providing invalid UID/GID values, terminates sss_seed tool without
any error message
https://fedorahosted.org/sssd/ticket/1554
sss_seed should not allow blank passwords
https://fedorahosted.org/sssd/ticket/1562
Domains overlap in range 1 - 4294967295
https://fedorahosted.org/sssd/ticket/1563
Document the need to restart autofs service.

== Detailed Changelog ==

Jakub Hrozek (11):
 * Bumping the version to 1.9.1 release
 * Document ldap_chpass_update_last_change
 * sudo and autofs search bases should not be marked experimental
 * Flip the default value of ldap_initgroups_use_matching_rule_in_chain
 * Include param_help_py.xml in the list of po4a sources
 * Note that Range Retrieval is not supported when filter is used in the search 
base.
 * Change the log level of two DEBUG messages in check_domain_ranges
 * Remove unused variable
 * Check for existing pidfile before starting the providers
 * man: Note that automounter must be restarted to re-read the master map
 * Updating the translations for 1.9.1 release

Jan Cholasta (2):
 * SSH: Refactor sysdb and related code
 * SSH: Expire hosts in known_hosts

Michal Zidek (7):
 * Change option to display help message in man pages.
 * sss_seed: Option --debug did not work in sss_seed tool.
 * sss_seed: Show error message when interactive input fails.
 * sss_seed: Make only first line of password file valid.
 * sss_seed: Passwords longer then PASS_MAX not allowed.
 * sss_seed: Improved error message when the domain does not exist.
 * Variable in sdap_sudo_rules_refresh_send could be used, uninitialized.

Ondrej Kos (4):
 * sssd-ldap manpage: ldap_scheme formatting
 * Log possibly non-randomizable ccache file template
 * Slices calculation is alway wrong for default values
 * Fix default upper limit of slices

[SSSD-users] Announcing SSSD 1.8.5

[Jakub Hrozek]

=== SSSD 1.8.5 ===

The SSSD team is proud to announce the bugfix release of the System
Security Services Daemon version 1.8.5.

As always, the source is available from https://fedorahosted.org/sssd

RPM packages will be made available for Fedora shortly, this time for
F-16 and F-17.

== Feedback ==

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

== Highlights ==
 * Fixed a potential segfault when SRV records are used to discover services
 * The client libraries now use robust mutexes to avoid a potential deadlock
   if a thread was cancelled while holding a mutex
 * Do not return an error when the SELinux support is not configured
 * Fixed returning an error to the PAM stack when the SSSD was performing
   authentication but the kpasswd server was unreachable
 * The SSSD used to skip a whole nesting level instead of a single already
   processed group when loading nested group membership structure
 * Added support for terminating idle connections and make the idle
   timeout configurable
 * The sss_ssh_knownostsproxy command no longer aborts when processing a
   host without DNS records
 * The shadowLastChange attribute is noe correctly updated with days since
   the Epoch, not seconds

== Tickets Fixed ==
 * https://fedorahosted.org/sssd/ticket/1356
SSH: Don't abort connection in sss_ssh_knownhostsproxy when DNS records are 
missing
 * https://fedorahosted.org/sssd/ticket/1271
Use HTML_TIMESTAMP instead of HTML_FOOTER_DESCRIPTION
 * https://fedorahosted.org/sssd/ticket/1360
Provide "service filter" for SELinux context
 * https://fedorahosted.org/sssd/ticket/1354
Add support for terminating idle connections
 * https://fedorahosted.org/sssd/ticket/1452
KRB5: Only return PAM error for unreachable kpasswd when performing chpass
 * https://fedorahosted.org/sssd/ticket/1419
Fixed wrong number in shadowLastChange
 * https://fedorahosted.org/sssd/ticket/1460
Use PTHREAD_MUTEX_ROBUST to avoid deadlock in the client
 * https://fedorahosted.org/sssd/ticket/1515
KRB5: Return PAM_AUTH_ERR on incorrect password
 * https://fedorahosted.org/sssd/ticket/1364
FO: Check server validity before setting status

== Detailed Changelog ==
Jakub Hrozek (8):
 * Use HTML_TIMESTAMP instead of HTML_FOOTER_DESCRIPTION
 * Send the correct enumeration request
 * Process all groups from a single nesting level
 * SYSDB: Make sysdb_attrs_get_el_int() public
 * KRB5: Only return PAM error for unreachable kpasswd when performing chpass
 * Use PTHREAD_MUTEX_ROBUST to avoid deadlock in the client
 * KRB5: Return PAM_AUTH_ERR on incorrect password
 * FO: Check server validity before setting status

Jan Cholasta (3):
 * SSH: Update sss_ssh_knownhostsproxy manual page
 * SSH: Supress error message output in sss_ssh_knownhostsproxy
 * SSH: Don't abort connection in sss_ssh_knownhostsproxy when DNS records are 
missing
 
Jan Zeleny (2):
 * Provide "service filter" for SELinux context
 * Fixed wrong number in shadowLastChange

Shantanu Goel (4):
 * Set return errno to the value prior to calling close().
 * Log message if close() fails in destructor.
 * Do not send SIGPIPE on disconnection
 * Add support for terminating idle connections

Stephen Gallagher (2):
 * Bumping version to 1.8.5
 * Make the client idle timeout configurable

Timo Aaltonen (1):
 * Move SELinux processing from session to account PAM stack
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] Announcing SSSD 1.9.2

[Jakub Hrozek]

=== SSSD 1.9.2 ===

The SSSD team is proud to announce the release of version 1.9.2 of
the System Security Services Daemon.

This is mostly a bugfix release again. I am going to branch off the 1.9
branch from master so that we can start including the 1.10 features in
master.

As always, the source is available from https://fedorahosted.org/sssd

RPM packages will be made available for Fedora shortly, initially for F-18
and rawhide and later also backported to F-17.

== Feedback ==

Please provide comments, bugs and other feedback via the sssd-devel or
sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

== Highlights ==
* Users or groups from trusted domains can be retrieved by UID or GID as 
well
* Several fixes that mitigate file descriptor leak during logins
* SSH host keys are also removed from the cache after being removed
  from the server
* Fix intermittent crash in responders if the responder was shutting
  down while requests were still pending
* Catch an error condition that might have caused a tight loop in the
  sssd_nss process while refreshing expired enumeration request
* Fixed memory hierarchy of subdomains discovery requests that caused
  use-after-free access bugs
* The krb5_child and ldap_child processes can print libkrb5 tracing
  information in the debug logs

== Tickets Fixed ==

https://fedorahosted.org/sssd/ticket/1008
Make sssd api conf file location configurable
https://fedorahosted.org/sssd/ticket/1319
group lookups optimizations for IPA
https://fedorahosted.org/sssd/ticket/1499
Add details about TGT validation to sssd-krb5 man page
https://fedorahosted.org/sssd/ticket/1512
[sssd[krb5_child[PID]]]: Credential cache directory /run/user/UID/ccdir 
does not exist
https://fedorahosted.org/sssd/ticket/1514
[abrt] sssd-1.8.4-13.fc16: __GI_exit: Process /usr/libexec/sssd/sssd_pam 
was killed by signal 6 (SIGABRT)
https://fedorahosted.org/sssd/ticket/1539
Collect Krb5 Trace on High Debug Levels
https://fedorahosted.org/sssd/ticket/1551
sssd_nss process hangs, stuck in loop; "self restart" does recover, but old 
process hangs around using 100% CPU
https://fedorahosted.org/sssd/ticket/1561
getting user/group entry by uid/gid sometimes fails
https://fedorahosted.org/sssd/ticket/1569
Use pam_set_data to close the fd in the pam module
https://fedorahosted.org/sssd/ticket/1571
sssd_nss intermittent crash
https://fedorahosted.org/sssd/ticket/1574
SSH host keys are not being removed from the cache

== Packaging Changes ==

* The libsss_sudo-devel package no longer contains the package-config
  file. The libsss_sudo-devel shared object has been moved to the
  libsss_sudo package.

== Detailed Changelog ==

E Deon Lackey (1):
* Fix language errors in the sssd-krb5.conf man page 

Jakub Hrozek (14):
* Bumping the version to 1.9.1 release
* Fix uninitialized pointer read in ssh_host_pubkeys_update_known_hosts
* Fix segfault when ID-mapping an entry without a SID
* Fix memory hierarchy in subdomains discovery
* PAM: close socket fd with pam_set_data
* Couple of specfile fixes
* Remove libsss_sudo.pc and move libsss_sudo.so to libsss_sudo
* Two fixes to child processes
* Collect krb5 trace on high debug levels
* PAM: fix handling the client fd in pam destructor
* Create ghost users when a user DN is encountered in IPA
* Only call krb5_set_trace_callback on platforms that support it
* MAN: improve wording of default_domain parameter
* Updating the translations for the 1.9.2 release 

Jan Cholasta (1):
* SSH: When host keys are removed from LDAP, remove them from the
  cache as well

Ondrej Kos (1):
* Add more info about ticket validation 

Pavel Březina (3):
* do not fail if POLLHUP occurs while reading data
* do not call dp callbacks when responder is shutting down
* nss_cmd_retpwent(): do not go into infinite loop if n < 0 

Sumit Bose (3):
* Save time of last get_domains request
* Check for subdomains if getpwuid or getgrgid are the first requests
* Allow extdom exop to return flat domain name as well 

Thorsten Scherf (1):
* Fixed: translation bug 

Yuri Chornoivan (1):
* Fix typos 

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

Re: [SSSD-users] sssd and difrent repositories

[Jakub Hrozek]

On Tue, Oct 16, 2012 at 10:21:02AM +, Longina Przybyszewska wrote:
> Hi list,
> I am going to set up proof-of -concept installation of Ubuntu (Precise) 
> client/server using sssd to authenticate/authorize
> against Active Directory.
> At this moment everything seems to be a challenge - as I am exclusive (ok ;-) 
> almost exclusive... ) hard core Linux user.
> 
> As our Windows team is not ready with AD schema for Unix - my first exercise 
> could be 
> -get login/ssh authenticate (and change passwd)  against AD
> -get uid/gid/auto.home map/shell from existing Linux NIS server
> 
> Is my plan realistic  ?

I'm not sure what version of the SSSD does Ubuntu Precise ship, but I
would recommend using 1.9.x and the AD provider. You might also want to
look into the realmd project, that could simplify joining an AD domain
for you.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] Active Directory Integration test day coming up on Thursday, 2012-10-18

[Jakub Hrozek]

Hi,

The Fedora Test day scheduled for Thursday, October 18th is focused on
Active Directory integration, in particular the realmd project and to some
extent the Active Directory provider of the SSSD.

This test day should be of particular interest to admins who manage Linux
boxes enrolled in an Active Directory domain.

As usual, join us in #fedora-test-day on FreeNode IRC. All the test
instructions are on the wiki:
https://fedoraproject.org/wiki/Test_Day:2012-10-18_Active_Directory

See the full feature page at if you'd like to learn more about the feature:
http://fedoraproject.org/wiki/Features/ActiveDirectory

If you are interested and have the spare cycles, please join us during
this Fedora Test day and help us make sure that Fedora 18 works with Active
Directory out of the box!
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd and different repositories

[Jakub Hrozek]

On Tue, Oct 16, 2012 at 01:25:00PM +, Longina Przybyszewska wrote:
> Sure, but I guess with sssd it should be simpler ( if it is possible).
> 

As me and Stephen said, with SSSD 1.9, the configuration is quite easy,
no need for NIS. In combination with the realmd project, even joining the
domain is quite simple.

By the way here is our documentation on using the SSSD in an AD domain
(that predates realmd):
https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Server

I just realized this document could have been better reachable from the
front page so I also linked it from
https://fedorahosted.org/sssd/wiki/Documentation
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] A test repository with SSSD 1.9 for RHEL-6.3

[Jakub Hrozek]

Hi,

even though RHEL-6.4 is still brewing, I think there might be some
interest in trying out the 1.9.x series of the SSSD on RHEL-6.3.

So I went ahead and built the SSSD 1.9.2 in a RHEL-6.3 buildroot:
http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/

The NVR of these test packages will be lower than those in 6.4 to keep
the upgrade path clean. The only missing functionality is the PAC
responder, which means this SSSD version won't be able to work with
an AD domain that is in a trust relationship with an IPA 3.x domain. I
had to disable the PAC responder as it requires Kerberos 1.10.

Because some new functionality required tweaking the SELinux policy, you
will encounter AVC denials when the new fast cache is accessed. That
said, my quick smoke testing went fine and we will be glad to hear test
results or bug reports.

Using the repository comes with a warning - this is NOT an official Red
Hat supported repository. The packages have NOT gone through formal QA. If
it breaks your RHEL-6.3 installation, you get to keep the pieces.

This is the repo configuration I used:
--
[sssd-1.9-RHEL6.3]
name=SSSD 1.9.x built for latest stable RHEL
baseurl=http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/$basearch/
enabled=1
skip_if_unavailable=1
gpgcheck=0

[sssd-1.9-RHEL6.3-source]
name=SSSD 1.9.x built for latest stable RHEL - Source
baseurl=http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/SRPMS
enabled=0
skip_if_unavailable=1
gpgcheck=0
--

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

Re: [SSSD-users] [SSSD] A test repository with SSSD 1.9 for RHEL-6.3

[Jakub Hrozek]

On Fri, Oct 19, 2012 at 08:48:56PM +0200, Trond Hasle Amundsen wrote:
> Jakub Hrozek  writes:
> 
> > even though RHEL-6.4 is still brewing, I think there might be some
> > interest in trying out the 1.9.x series of the SSSD on RHEL-6.3.
> >
> > So I went ahead and built the SSSD 1.9.2 in a RHEL-6.3 buildroot:
> > http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/
> >
> > The NVR of these test packages will be lower than those in 6.4 to keep
> > the upgrade path clean. The only missing functionality is the PAC
> > responder, which means this SSSD version won't be able to work with
> > an AD domain that is in a trust relationship with an IPA 3.x domain. I
> > had to disable the PAC responder as it requires Kerberos 1.10.
> >
> > Because some new functionality required tweaking the SELinux policy, you
> > will encounter AVC denials when the new fast cache is accessed. That
> > said, my quick smoke testing went fine and we will be glad to hear test
> > results or bug reports.
> 
> Hello Jakub and the SSSD team,
> 
> My interest in the 1.9 version is first and foremost the performance
> enhancements related to large groups. At our site, we have lots of
> fairly large file groups and a few enormous ones (which we're getting
> rid of but it takes some time). I installed sssd-1.9 from your test repo
> on a rhel6.3 VM, ran a couple of quick tests and compared it to an
> identical VM with the stock sssd-1.8 from rhel6.3. The results are
> astonishing:
> 
> Test 1: time getent group 
> 
>   sssd-1.9.2-1.el6_3.x86_64:  0m1.087s
>   sssd-1.8.0-32.el6.x86_64:   0m5.937s
> 
> Test 2: time id 
> 
>   sssd-1.9.2-1.el6_3.x86_64:  0m9.669s
>   sssd-1.8.0-32.el6.x86_64:   1m28.578s
> 
> Both tests were done without a preexisting cache, i.e. 'service sssd
> stop; rm /var/lib/sss/db/*; service sssd start', then run test. We're
> using plain LDAP (rfc3207) as id provider and auth provider.
> 
> This is a remarkable performance boost, and I can't wait to see an
> official sssd-1.9 package in rhel6. Thanks for all your hard work and
> have a nice weekend! :)
> 

This is great to hear, Trond. Thank you for taking the time to test the
pre-release packages. I'm glad the performance has improved for you! I
believe that the in-memory fast cache would provide even bigger boost
for groups and users that are being accessed regularly.

> PS. Will we see sssd-1.9 in Fedora 17?

Yes, as a matter of fact it might be the time to put 1.9 into
updates-testing.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] startup problem

[Jakub Hrozek]

On Wed, Oct 24, 2012 at 03:55:27PM +, Longina Przybyszewska wrote:
> Hi again,
>  Ubuntu-quantal -  sssd-1.9.1 
> 
> Can start sssd in interactive mode , but cannot start it from init scripts as 
> a deamon
> with "-D -f -d3" options
> 
> /etc/ssd/sssd.conf  mode 600
> 
> longina

Is there anything in logs, either syslog or the SSSD logs?
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] startup problem

[Jakub Hrozek]

On Wed, Oct 24, 2012 at 04:34:02PM +, Longina Przybyszewska wrote:
> No.
> In syslog, only messages from /usr/sbin/sssd -i  (Starting up/shutting down)
> 
> I disabled sssd from apparmor.
> 

Can you strace what the initscript does? I guess it actually is starting
the sssd.

If you put debug_level=10 into the [sssd] section, is there anything
helpful in /var/log/sssd/*.log?

> By the way - I tried to compile the 1.9.2 version (Ubuntu-quantal) , but 
> stack on missing  openladap;
> I downloaded  openldap-utils - doesn’t help; 

Was there a compile error or configure error?
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] startup problem

[Jakub Hrozek]

On Wed, Oct 24, 2012 at 04:51:30PM +, Longina Przybyszewska wrote:
> 
> > By the way - I tried to compile the 1.9.2 version (Ubuntu-quantal) , 
> > but stack on missing  openladap; I downloaded  openldap-utils - 
> > doesn’t help;
> 
> Was there a compile error or configure error?
> 
> Configure ..
> 
> Opanldap package doesn't findes in repository.
> Only openldap-utils

You need the equivalent of openldap-devel for Ubuntu. I don't know what
the package is called there.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd equivilent of nss_ldap nss_getgrent_skipmembers?

[Jakub Hrozek]

On Thu, Oct 25, 2012 at 05:43:12AM -0400, Stephen Gallagher wrote:
> On 10/24/2012 05:49 PM, Paul B. Henson wrote:
> >We're working on transitioning from RHEL5 to RHEL6 and have run into a
> >bit of a problem with sssd and our ldap integration.
> >
> >We have a number of groups with a very large number of members, which
> >took excessively long with nss_ldap to retrieve. We implemented the
> >nss_getgrent_skipmembers feature for nss_ldap, got it accepted into the
> >PADL upstream, talked Red Hat into backporting it, and have been
> >using it for years. Basically, this feature allows you to not request
> >the member attribute for a group lookup, the group shows up with no members.
> >However, for the purposes of initgroups, membership is still taken into
> >account and users belong to the correct groups. This works perfectly for
> >our needs.
> >
> 
> Paul, this has been proposed as
> https://fedorahosted.org/sssd/ticket/1376 which is currently slated
> for inclusion in SSSD 1.10. You're not the first person to request
> this functionality, but it just hasn't been implemented yet.
> 
> Also, as Dmitri has stated, in the case of initgroups (which can be
> tested with 'id -G username' SSSD 1.9.x has implemented several very
> serious performance increases.
> 
> Please test with 'id -G' and not just 'id', as the latter doesn't
> just get the user's group memberships but also retrieves the full
> contents of each of the groups.

There has also been many performance improvements done during the 1.9
development. I would suggest that you try the 1.9 packages to see if the
performance is acceptable for you.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Different SSSD LDAP search filters for specific PAM services

[Jakub Hrozek]

On Thu, Oct 25, 2012 at 01:48:49PM +0200, Tomas Brandysky wrote:
> On 10/25/2012 11:36 AM, Sumit Bose wrote:
> > On Thu, Oct 25, 2012 at 10:36:05AM +0200, Tomas Brandysky wrote:
> >> Hello,
> >>
> >> we're upgrading from Centos 5.8 to Centos 6.3 and have realized few
> >> things have changed in the system.
> >>
> >> We're using LDAP authentication (nss_ldap package) on our Centos 5.8
> >> servers and have different PAM ldap configuration files configured to be
> >> used for specific PAM services at the moment.
> >>
> >> Here is the example of our setup:
> >>
> >> /etc/pam.d/service1:
> >>  authsufficientpam_ldap.so config=/etc/ldap_service1.conf
> >>
> >> /etc/pam.d/service2:
> >>  authsufficientpam_ldap.so config=/etc/ldap_service2.conf
> >>
> >> Thus we can use specific LDAP filters for various different services as
> >> not all users having access to one service also have access to other
> >> services on the same server.
> >>
> >> Now we're facing the problem to manage the same functionality with
> >> System Security Services Daemon (SSSD) which was newly presented with
> >> RHEL 6.
> >>
> >> We didn't find out so far how to specify custom sssd configuration file
> >> (or specific part of the configuration section/domain) in PAM service
> >> configuration. According to documentation only these options can be
> >> specified when using pam_sss module: [forward_pass] [use_first_pass]
> >> [use_authtok].
> >>
> >> None of them can be used to make a difference in a ldap filter to be used.
> >>
> >> Is there a way how to configure specific search filters depending on PAM
> >> service ?
> >>
> >> Thank you for any suggestion
> > 
> > I think what you are looking for is covered in
> > https://fedorahosted.org/sssd/ticket/1021.
> > 
> 
> yes, that's exactly what I miss in sssd.
> I'm surprised such a feature isn't supported yet as the same goal could
> be accomplished in RHEL4/5 releases with older methods. I see this as a
> step back. Is there some real possibility to have this feature in some
> later release which could come as update in RHEL 6 ?

I don't think we are tracking this feature request for RHEL6. If
you need the functionality in RHEL6, feel to propose it through the
support.

> 
> > If you only want to allow/deny access for specific users to specific
> > service you can add an attribute to the user objects in the LDAP server
> > listing the allowed PAM services and use ldap_user_authorized_service.
> > See sssd-ldap man page for details.
> 
> I know about ldap_user_authorized_service but I need to specify a
> combination of service and host access. I can't effort to grant users
> access to ssh service globaly when they can access ssh only on some of
> dozens servers we have.
> 

You can also use a comma-separated list in the ldap_access_order
parameter of sssd.conf and then define both service and host for a user.

For a finer-grained access control, you probably want IPA's HBAC as
Sumit said.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd equivilent of nss_ldap nss_getgrent_skipmembers?

[Jakub Hrozek]

On Thu, Oct 25, 2012 at 03:13:17PM -0700, Paul B. Henson wrote:
> On 10/25/2012 2:43 AM, Stephen Gallagher wrote:
> 
> >Paul, this has been proposed as
> >https://fedorahosted.org/sssd/ticket/1376 which is currently slated for
> >inclusion in SSSD 1.10. You're not the first person to request this
> >functionality, but it just hasn't been implemented yet.
> 
> Cool. Is anybody actively working/planning to work on this? I notice
> it is currently owned by "somebody" :). We're fairly hands on, if
> nobody else is currently working on this we might take a look at it.
> 

Nobody is working on that as far as I know.

We would certainly welcome patches, feel free to visit the #sssd channel
on Freenode. Most of us hang around there -- some of the SSSD developers
are in the EU timezones, some are in the US, so there would be a person
to answer a question pretty much all the time. Don't hesitate to ask
there on the sssd-devel mailing list!

A good place to start would be the "Contribute" page:
https://fedorahosted.org/sssd/wiki/Contribute

There's also an assorted collection of developer-oriented tips:
https://fedorahosted.org/sssd/wiki/DevRes
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd equivilent of nss_ldap nss_getgrent_skipmembers?

[Jakub Hrozek]

On Thu, Oct 25, 2012 at 03:21:26PM -0700, Paul B. Henson wrote:
> On 10/25/2012 4:03 AM, Jakub Hrozek wrote:
> 
> >There has also been many performance improvements done during the 1.9
> >development. I would suggest that you try the 1.9 packages to see if the
> >performance is acceptable for you.
> 
> I compiled the latest 1.9.2 source release on a test RHEL6 system,
> and it does indeed have a dramatic performance improvement:
> 
> # time getent group members
> 1.8.0 -- 1m29.589s
> 1.9.2 -- 0m5.968s
> 
> # time getent group students
> 1.8.0 -- 0m44.735s
> 1.9.2 -- 0m4.543s
> 
> # time id -a cpcrudo
> 1.8.0 -- 2m14.719s
> 1.9.2 -- 0m12.508s

I assume you ran these with a cold cache?

The other feature of the 1.9.x series is a new in-memory cache which
should return results pretty much instantly.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Different SSSD LDAP search filters for specific PAM services

[Jakub Hrozek]

On Fri, Oct 26, 2012 at 11:10:45AM +0200, Tomas Brandysky wrote:
> > You can also use a comma-separated list in the ldap_access_order
> > parameter of sssd.conf and then define both service and host for a user.
> > 
> 
> this is not a solution because defining service for user in LDAP means
> to grant user access to this service not only on a particular server but
> on all servers the same user can access too (for example because of some
> other services).
> 
> This is real scenario:
> 
> - two servers both running openvpn and ssh services - both configured to
> authenticate users against LDAP
> 
> - I want user "one" to have access to:
>  - openvpn service on server1
>  - ssh service on server2
> 
> 
> I'm not able to manage this with sssd even though I try it with comma-
> separated list in the ldap_access_order parameter. I don't think this
> scenario is so rare in other companies too. This is a quite common
> practice in larger companies maintaining dozens of servers and services
> to grant users access to specific services on specific servers only (as
> we can do easily with pam_ldap).
> 
> I will be very surprised if many other companies won't request this
> feature being present in sssd if this is a new official way how to
> handle LDAP authentication in RHEL 6.
> 
> 
> > For a finer-grained access control, you probably want IPA's HBAC as
> > Sumit said.
> 
> I got a look to at IPA's HBAC and it seems to be overkill to me. I can
> imagine such a solution in very large enterprises where kinda more
> sophisticated integrated security information management solution might
> come in handy.
> 
> I think our company(as many others) will stick with "old" pam_ldap
> solution which was there working since RHEL4. At least until this
> feature is integrated to sssd.
> 
> Tomas

I'm sorry the current means of access control do not work for you.

Unfortunately we have finite time and resources and the next 1.10 release
is already getting quite big. I would suggest raising a feature request
via the usual RHEL channels to bump the priority up.

Or, if you'd be willing to work with us and contribute a patch, I'll be
glad to help with getting you up to speed and getting the patch
accepted upstream.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] startup problem/port status 0

[Jakub Hrozek]

On Tue, Nov 06, 2012 at 02:16:26PM +, Longina Przybyszewska wrote:
> Hi again,
> Thanks a lot for guiding me so far :)
> 
> I have got sssd-1.9.2 package from Timo, Ubuntu sssd package maintainer for  
> Ubuntu Quantal.
> 
> SSSD is configured against  AD as auth/id - provider
> 
> sssd.conf
> 
> [sssd]
> debug_level = 0x1310
> config_file_version = 2
> services = nss, pam
> domains = nat.c.sdu.dk
> 
> [nss]
> filter_groups = root
> filter_users = root
> 
> [pam]
> 
> [domain/nat.c.sdu.dk]
> 
> debug_level = 0x1310
> 
> enumerate = False
> min_id = 1000
> max_id = 2
> 
> auth_provider = ad
> id_provider = ad
> access_provider = ad
> chpass_provider = ad
> 
> ad_server = nat.c.sdu.dk
> ad_hostname = testina4$.nat.c.sdu.dk
> ad_domain = nat.c.sdu.dk
> 
> 
> From  log:
> (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] 
> [be_resolve_server_process] (0x1000): Saving the first resolved server
> (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] 
> [be_resolve_server_process] (0x0200): Found address for server nat.c.sdu.dk: 
> [10.144.5.18] TTL 455
>  (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [sasl_bind_send] 
> (0x0100): Executing sasl bind mech: gssapi, user: testina4$
> (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [fo_set_port_status] 
> (0x0100): Marking port 0 of server 'nat.c.sdu.dk' as 'not working
> (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [fo_resolve_service_send] 
> (0x0100): Trying to resolve service 'AD'
> (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [get_server_status] 
> (0x1000): Status of server 'nat.c.sdu.dk' is 'name resolved'
> (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [get_port_status] 
> (0x1000): Port status of port 0 for server 'nat.c.sdu.dk' is 'not working'
> (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [be_resolve_server_done] 
> (0x1000): Server resolution failed: 5
> (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [acctinfo_callback] 
> (0x0100): Request processed. Returned 1,11,Offline
> (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [remove_krb5_info_files] 
> (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.NAT.C.SDU.DK], 
> [2][No such file or directory
> 

There is not all the information in the log, raising the debug_level
might provide more info, but I think the problem is in the kinit.

Can you kinit as the principal specified in the ad_hostname and then
ldapsearch the directory?

Are you sure about the principal in ad_hostname? I think it is typically
HOST$@DOMAIN, your principal doesn't contain the at-sign.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] netgroups alternative?

[Jakub Hrozek]

On Thu, Nov 08, 2012 at 10:41:28AM +0100, Ondrej Valousek wrote:
> Hi List,
> 
> Quick question (maybe not the right one for this list). Is there any 
> alternative for netgroups in Linux?
> I mean netgroups are tightly bound to NIS which is insecure piece of
> crap so I wonder if there is any new alternative which should (can)
> be used in any new deployment.
> 
> Thanks!
> Ondrej

HBAC is the best solution, I think.

Other than that, access control can be also set per service and per host
in LDAP, see ldap_user_authorized_service or ldap_user_authorized_host.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] A test repository with SSSD 1.9 for RHEL-6.3

[Jakub Hrozek]

On Thu, Nov 08, 2012 at 06:17:40PM +0100, Ondrej Valousek wrote:
> Ok, I gave it a try (with an AD provider) and here are the bugs I have found 
> so far:
> 
> 0. My configuration:
> id_provider = ad
> auth_provider = ad
> chpass_provider = ad
> cache_credentials = True
> ldap_id_mapping = False
> # ldap_sasl_authid = LOGINA$@DUBLIN.AD.S3GROUP.COM
> 
> 1. Upgrade db database from the 1.8 versions (aka RHEL 6U3) does not
> work. SSSD won't start (dies silently). I had to rm
> /var/lib/sss/db/* to make it working.

This is pretty bad. Do you still have the old database somewhere or
the possibility of generating it again with old packages? We haven't
seen this bug so far in our testing, but apparently it's out there..

> 2. sssd won't work when I specify correct ldap_sasl_authid (see the
> example above). This is bad as I might have my krb5.keytab cluttered
> with other (possibly not working) keys so I would like to keep the
> possibility of specifying the ldap_sasl_authid manually.

So this is authid that was working with the plain ldap provider but
dosn't work with ad provider? Can you share logs? 

Have you tried if using this authid works even with 1.9 with the ldap
provider?

> 3. This is a show stopper for me. I can not disable ID mapping as the example 
> above does not work for me:
> 
> Desired results:
> Only users and groups w/ RFC2307 attributes are seen, NO id mapping is 
> performed.
> Achieved results:
> Users and groups who have defined RFC2307 attributes are displayed
> fine (RFC2307 attributes honored), but also users & groups with no
> RFC2307 attributes are displayed (RFC2307 attributes computed by
> sssd)
> 

I suspect that this issue might be fixed in the latest builds. I was
planning to upgrade this preview repo to 1.9.3 when it becomes ready,
but it wouldn't be too hard to include the fixes we have so far so you
could test.

> Ondrej
> 

Thank you very much for testing.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] startup problem/port status 0

[Jakub Hrozek]

On Thu, Nov 08, 2012 at 03:38:47PM +, Longina Przybyszewska wrote:
> In /etc/sssd/sssd.conf
> 
> ..
> Ad_hostname = VICTORIA$@NAT.C.SDU.DK
> ..

It should be "ad_hostname" (note the capital A) and it's only useful for
specifying the machine hostname in case the output of hostname command
wouldn't reflect the real host name..


Does it work if you set:

ad_hostname = VICTORIA$
krb5_realm = NAT.C.SDU.DK

(VICTORIA$@NAT.C.SDU.DK was the one that worked for you, right?)

If it doesn't, can you raise debugging in the domain section, restart
the sssd, try again and look for lines that mention "ldap_child" ? You
would see the principal used there.

> IT is obviously confusing about principal names...
> 
> Longina
> 
> 
> 
> 
> 
> 
> -Original Message-
> From: sssd-users-boun...@lists.fedorahosted.org 
> [mailto:sssd-users-boun...@lists.fedorahosted.org] On Behalf Of Jakub Hrozek
> Sent: 8. november 2012 10:54
> To: sssd-users@lists.fedorahosted.org
> Subject: Re: [SSSD-users] startup problem/port status 0
> 
> On Tue, Nov 06, 2012 at 02:16:26PM +, Longina Przybyszewska wrote:
> > Hi again,
> > Thanks a lot for guiding me so far :)
> > 
> > I have got sssd-1.9.2 package from Timo, Ubuntu sssd package maintainer for 
> >  Ubuntu Quantal.
> > 
> > SSSD is configured against  AD as auth/id - provider
> > 
> > sssd.conf
> > 
> > [sssd]
> > debug_level = 0x1310
> > config_file_version = 2
> > services = nss, pam
> > domains = nat.c.sdu.dk
> > 
> > [nss]
> > filter_groups = root
> > filter_users = root
> > 
> > [pam]
> > 
> > [domain/nat.c.sdu.dk]
> > 
> > debug_level = 0x1310
> > 
> > enumerate = False
> > min_id = 1000
> > max_id = 2
> > 
> > auth_provider = ad
> > id_provider = ad
> > access_provider = ad
> > chpass_provider = ad
> > 
> > ad_server = nat.c.sdu.dk
> > ad_hostname = testina4$.nat.c.sdu.dk
> > ad_domain = nat.c.sdu.dk
> > 
> > 
> > From  log:
> > (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [be_resolve_server_process] (0x1000): Saving the first resolved server 
> > (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [be_resolve_server_process] (0x0200): Found address for server 
> > nat.c.sdu.dk: [10.144.5.18] TTL 455  (Tue Nov  6 13:42:35 2012) 
> > [sssd[be[nat.c.sdu.dk]]] [sasl_bind_send] (0x0100): Executing sasl bind 
> > mech: gssapi, user: testina4$ (Tue Nov  6 13:42:35 2012) 
> > [sssd[be[nat.c.sdu.dk]]] [fo_set_port_status] (0x0100): Marking port 0 of 
> > server 'nat.c.sdu.dk' as 'not working (Tue Nov  6 13:42:35 2012) 
> > [sssd[be[nat.c.sdu.dk]]] [fo_resolve_service_send] (0x0100): Trying to 
> > resolve service 'AD'
> > (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [get_server_status] 
> > (0x1000): Status of server 'nat.c.sdu.dk' is 'name resolved'
> > (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [get_port_status] 
> > (0x1000): Port status of port 0 for server 'nat.c.sdu.dk' is 'not working'
> > (Tue Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [be_resolve_server_done] (0x1000): Server resolution failed: 5 (Tue 
> > Nov  6 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [acctinfo_callback] 
> > (0x0100): Request processed. Returned 1,11,Offline (Tue Nov  6 
> > 13:42:35 2012) [sssd[be[nat.c.sdu.dk]]] [remove_krb5_info_files] 
> > (0x0200): Could not remove 
> > [/var/lib/sss/pubconf/kpasswdinfo.NAT.C.SDU.DK], [2][No such file or 
> > directory
> > 
> 
> There is not all the information in the log, raising the debug_level might 
> provide more info, but I think the problem is in the kinit.
> 
> Can you kinit as the principal specified in the ad_hostname and then 
> ldapsearch the directory?
> 
> Are you sure about the principal in ad_hostname? I think it is typically 
> HOST$@DOMAIN, your principal doesn't contain the at-sign.
> ___
> 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
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] A test repository with SSSD 1.9 for RHEL-6.3

[Jakub Hrozek]

On Fri, Nov 09, 2012 at 08:41:57AM +0100, Ondrej Valousek wrote:
> >Do you have any logs perchance ?
> Have only this:
> (Thu Nov  8 16:10:57 2012) [sssd] [sysdb_upgrade_10] (0x0020): UPGRADING DB 
> TO VERSION 0.11
> (Thu Nov  8 16:10:57 2012) [sssd] [sysdb_error_to_errno] (0x0020): LDB 
> returned unexpected error: [No such attribute]
> 
> Ondrej

Thank you, that at least tells us which of the three DB upgrades we did
during the 1.9 development broke. For the record, the changes were:

* 0.11 - fake users to ghost users
* 0.12 - different schema for autofs entries
* 0.13 - introduce sshKnownHostsExpire and index them

I know you are using AD, so the best way for us to try and replicate the
problem would be to try upgrading different nested group structures. Is
there anything else peculiar about your setup? Groups with no users,
non-posix (=lacking GID) groups etc?

Of course, if you could reproduce the problem again and send us more
verbose logs, that would be even more helpful..

Anyway, this problem is now being tracked as:
https://fedorahosted.org/sssd/ticket/1631
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sssd 1.9.2 & autofs & AD does not work

[Jakub Hrozek]

On Fri, Nov 09, 2012 at 10:01:29AM +0100, Ondrej Valousek wrote:
> Hi,
> 
> I am using sssd 1.9.2 with AD provider and I would like to use it for autofs 
> support, too.
> Unfortunately 'autofs_provider = ad' is not working at all. I tried
> 'autofs_provider = ldap', it tries to search for maps, but
> eventually it fails as well:
> 
> (Fri Nov  9 08:33:31 2012) [sssd[be[default]]] [sdap_autofs_handler] 
> (0x0200): Requested refresh for: auto.master
> (Fri Nov  9 08:33:31 2012) [sssd[be[default]]] 
> [sdap_get_automntmap_next_base] (0x0400): Searching for automount maps with 
> base [CN=dublin,xxx]
> (Fri Nov  9 08:33:31 2012) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> [(&(nisMapName=auto.master)(objectclass=nisMap))][CN=dublin,xxx].
> (Fri Nov  9 08:33:31 2012) [sssd[be[default]]]
> [sdap_autofs_setautomntent_done] (0x0040): sdap_get_automntmap_recv
> failed [5]: Input/output error
> 
> Is this configuration supported please?
> Thanks,
> Ondrej

Yes, it should work..

Do you have the same error with autofs_provider = ad and autofs_provider
= ldap?

Is there nothing more in the logs even if you set the highest debug
level?

Is it possible to search autofs maps from the command line with:
ldapsearch -Y GSSAPI -b CN=dublin,xxx 
'(&(nisMapName=auto.master)(objectclass=nisMap))'
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] SSSD 1.8.0-32 and AD with RHEL6

[Jakub Hrozek]

On Thu, Nov 08, 2012 at 11:01:33AM -0600, James Chambers wrote:
> Hello,
> 
> I was told by a user in linuxquestions.org to try this list for help.
> 
> So we've been trying to get SSSD working with AD on RHEL 6 for about a week
> now. we've been trying to following
> http://www.redhat.com/resourcelibrary/reference-architectures/integrating-red-hat-enterprise-linux-6-with-active-directory
> 
> As 1.8.0-32 is part of the latest install of RHEL 6, that's the version we
> need to use.
> 
> We can get configuration number 6.4 kerboros/ldap working just fine and SSH
> with that, but we want option 6.3 SSSD/kerboros/ldap for the caching
> features.
> 
> When 6.3 option is enabled, we can do a ldapsearch just fine with
> ldapsearch -Y GSSAPI -N "(sAMAccountName=username)"
> 
> It's when we try to SSH on the server is when we are unable to get it to
> work. We do ssh - username@servername and get a permission denied when
> we do the password
> 
> In /var/log/messages we get:
> GSSAPI Error: Unspecified GSS failure. Minor code may prove more
> information (Matching credential not found)
> 
> In /var/log/secure, we get:
> Invalid user username from ipaddress
> input_userauth_request: invalid user username
> pam_unix(sshd:auth): check pass; user unknown
> pam_unix(sshd:auth: authentication failure; logname= uid=0 euid=0 tty=ssh
> ruser= rhost=servername
> pam_succeed_if(sshd:auth): error retriving information about user username
> Failed password for invalid user username from ipaddress port portid SSH2
> 
> Here is the /var/sssd/sssd.conf file:
> [sssd]
> services = nss, pam
> config_file_version = 2
> debug_level = 9
> domains = default
> 
> [nss]
> 
> [pam]
> 
> [domain/default]
> debug_level = 9
> enumerate = false
> id_provider = ldap
> chpass_provider = krb5
> case_sensitive = false
> ldap_uri = ldap://ldapservername.domain.domain.domain
> ldap_search_base = dc=domain,dc=domain,dc=domain
> ldap_user_search_base = dc=domain,dc=domain,dc=domain
> ldap_group_search_base = dc=domain,dc=domain,dc=domain
> ldap_id_use_start_tls = true
> ldap_schema = rfc2307bis
> ldap_sasl_mech = GSSAPI
> ldap_force_upper_case_realm = true
> ldap_krb5_keytab = /etc/krb5.keytab
> ldap_sasl_authid = host/servername.domain.domain.domain@DOMAIN.DOMAIN.DOMAIN
> 
> auth_provider = krb5
> cache_credentials = true
> krb5_realm = DOMAIN.DOMAIN.DOMAIN
> krb5_server = ldapservername.DOMAIN.DOMAIN.DOMAIN
> krb5_ccachedir = /tmp
> krb5_auth_timeout = 15
> 
> ldap_user_object_class = user
> ldap_user_modify_timestamp = whenChanged
> ldap_user_home_directory = unixHomeDirectory
> ldap_user_princical = userPrincipalName
> ldap_user_name = sAMAccountName
> ldap_user_shell = loginShell
> ldap_user_uid_number = uidNumber
> ldap_user_gid_number = gidNumber
> ldap_group_object_class = group
> ldap_group_modify_timestamp = whenChanged
> ldap_group_name = sAMAccountName
> ldap_group_gid_number = gidNumber
> 
> krb5_kpasswd = ldapservername.domain.domain.domain
> 
> access_provider = ldap
> ldap_access_order = expire
> ldap_account_expire_policy = ad
> ldap_tls_cacertdir = /etc/openldap/cacerts
> ldap_disable_referrals = true
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> I've tried changing around access_provider to simple or permit and it
> didn't work. I tried added ladp_access_filter to allow my id and tried
> objectClass=user and it didn't work. I modified the sssd.conf file based on
> another one I found at zews.org/rhel6-active-directory
> 
> Here is the password_auth file:
> auth required pam_env.so
> auth sufficient pam.unix.so nullok try_first_pass
> auth requisite pam_succeed_if.so uid >= 500 quiet
> auth sufficient pam_sss.so use_first_pass
> auth required pam_deny.so
> 
> account required pam_unix.so broken_shadow
> account sufficient pam_localuser.so
> account sufficient pam_succeed_if.so uid < 500 quiet
> account [default=bad success=ok user_unknown=ignore] pam_sss.so
> account required pam_permit.so
> 
> password requisite pam_cracklib.so try_first_pass retry_3 type=
> password sufficient pam_unix.so shadow nullok try_first_pass use_authtok
> password sufficient pam_sss.so use_authtok
> password required pam_deny.so
> 
> session optional pam_keyinit.so revoke
> session required pam_limits.so
> session optional pam_oddjob_mkhomedir.so
> session [success=1 default=ignore] pam_succeed_if.so service in crond quiet
> use_uid
> session required pam_unix.so
> session optional pam_sss.so
> 
> nsswitch.conf has the following:
> passwd: files sss
> shadow: files sss
> group: files sss
> 
> ldap_child.log gives me the following:
> [unpack_buffer] (0x1000): total buffer size 94
> [unpack_buffer] (0x1000): realm_str size: 15
> [unpack_buffer] (0x1000): got realm_str: DOMAIN.DOMAIN.DOMAIN
> [unpack_buffer] (0x1000): princ_str size: 47
> [unpack_buffer] (0x1000): got princ_str:
> host/server.domain.domain.domain@DOMAIN.DOMAIN.DOMAIN
> [unpack_buffer] (0x1000): keytab_name size = 16
> [unpack_buffer] (0x1000): got keytab_name: /etc/krb5.keytab
> [unpack_buff

Re: [SSSD-users] startup problem/port 0 not working

[Jakub Hrozek]

On Fri, Nov 09, 2012 at 11:15:25AM +, Longina Przybyszewska wrote:
> It is "ad_hostname=VICTORIA$@NAT.C.SDU.DK"  - this is my mail editor starting 
> with capital letter after "." ;(
> 
> I joined domain (again, again..) from scratch.
> 
> ad_hostname = VICTORIA$NAT.C.SDU.DK
> 
> I have the following principal names bound to computer victoria.nat.sdu.dk
> root@victoria:/var/log/sssd# ldapsearch  -E pr=1000/noprompt -H 
> ldap://nat.c.sdu.dk -Y GSSAPI  -b 'ou=Linux 
> computers,ou=ADResources,dc=nat,dc=c,dc=sdu,dc=dk' 
> '(&(objectClass=computer)(name=victoria))'
> 
> # VICTORIA, Linux computers, ADResources, nat.c.sdu.dk
> dn: CN=VICTORIA,OU=Linux computers,OU=ADResources,DC=nat,DC=c,DC=sdu,DC=dk
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: user
> objectClass: computer
> cn: VICTORIA
> distinguishedName: CN=VICTORIA,OU=Linux computers,OU=ADResources,DC=nat,DC=c,D
>  C=sdu,DC=dk
> ...
> name: VICTORIA
> ...
> sAMAccountName: VICTORIA$
> sAMAccountType: 805306369
> dNSHostName: victoria.nat.c.sdu.dk
> userPrincipalName: victoria.nat.sdu...@nat.c.sdu.dk
> servicePrincipalName: host/victoria.nat.c.sdu.dk
> 
> ...
> I can kinit as admin aduser.
> I can kinit as principal VICTORIA$ and VICTORIA$NAT.C.SDU.DK

OK, then the keytab seems fine.

> 
> I can as local root get info on computer 'victoria' and ad user 
> 'imadatestuser':
>  
> ldapsearch  -E pr=1000/noprompt -H ldap://nat.c.sdu.dk -Y GSSAPI  -b 
> 'ou=Linux computers,ou=ADResources,dc=nat,dc=c,dc=sdu,dc=dk' 
> '(&(objectClass=computer)(name=victoria))'
> root@victoria:/var/log/sssd# ldapsearch  -E pr=1000/noprompt -H 
> ldap://nat.c.sdu.dk -Y GSSAPI -b 'ou=ADusers,dc=nat,dc=c,dc=sdu,dc=dk' 
> '(&(objectClass=person)(sAMAccountName=imadatestuser))'
> 
> I can kinit imadatestuser
> 
> BUT login as imadatestuser and ' getent passwd imadatestuser' doesn't work - 
> still the same error  on "port 0"
> What is "port 0" ???

For server that "aggregate" LDAP and Kerberos such as AD or IPA, we don't
want to be talking to a different box in the same domain on LDAP port and
different box on Kerberos port.

So instead of using 389 for LDAP and 88 for Kerberos separately, we use
kind of a hack of using port 0 in the fail over code only to force the SSSD
to talk to a single AD/IPA server for both LDAP and Kerberos. Internally,
when establishing the network connection, we use the real ports of 389
and 88 of course.

> 
> Ldap_child.log
> (Fri Nov  9 11:50:07 2012) [[sssd[ldap_child[4438 [unpack_buffer] 
> (0x1000): total buffer size: 37
> (Fri Nov  9 11:50:07 2012) [[sssd[ldap_child[4438 [unpack_buffer] 
> (0x1000): realm_str size: 12
> (Fri Nov  9 11:50:07 2012) [[sssd[ldap_child[4438 [unpack_buffer] 
> (0x1000): got realm_str: NAT.C.SDU.DK
> (Fri Nov  9 11:50:07 2012) [[sssd[ldap_child[4438 [unpack_buffer] 
> (0x1000): princ_str size: 9
> (Fri Nov  9 11:50:07 2012) [[sssd[ldap_child[4438 [unpack_buffer] 
> (0x1000): got princ_str: VICTORIA$
> (Fri Nov  9 11:50:07 2012) [[sssd[ldap_child[4438 [unpack_buffer] 
> (0x1000): keytab_name size: 0
> (Fri Nov  9 11:50:07 2012) [[sssd[ldap_child[4438 [unpack_buffer] 
> (0x1000): lifetime: 86400
> (Fri Nov  9 11:50:07 2012) [[sssd[ldap_child[4438 
> [ldap_child_get_tgt_sync] (0x0100): Principal name is: 
> [VICTORIA$@NAT.C.SDU.DK]
> (Fri Nov  9 11:50:07 2012) [[sssd[ldap_child[4438 
> [ldap_child_get_tgt_sync] (0x0100): Using keytab [default]
> (Fri Nov  9 11:50:07 2012) [[sssd[ldap_child[4438 [pack_buffer] (0x1000): 
> result [0] krberr [0] msgsize [40] msg 
> [FILE:/var/lib/sss/db/ccache_NAT.C.SDU.DK]
> (Fri Nov  9 11:51:39 2012) [[sssd[ldap_child[4441 [unpack_buffer] 
> (0x1000): total buffer size: 37
> (Fri Nov  9 11:51:39 2012) [[sssd[ldap_child[4441 [unpack_buffer] 
> (0x1000): realm_str size: 12
> (Fri Nov  9 11:51:39 2012) [[sssd[ldap_child[4441 [unpack_buffer] 
> (0x1000): got realm_str: NAT.C.SDU.DK
> (Fri Nov  9 11:51:39 2012) [[sssd[ldap_child[4441 [unpack_buffer] 
> (0x1000): princ_str size: 9
> (Fri Nov  9 11:51:39 2012) [[sssd[ldap_child[4441 [unpack_buffer] 
> (0x1000): got princ_str: VICTORIA$
> (Fri Nov  9 11:51:39 2012) [[sssd[ldap_child[4441 [unpack_buffer] 
> (0x1000): keytab_name size: 0
> (Fri Nov  9 11:51:39 2012) [[sssd[ldap_child[4441 [unpack_buffer] 
> (0x1000): lifetime: 86400
> (Fri Nov  9 11:51:39 2012) [[sssd[ldap_child[4441 
> [ldap_child_get_tgt_sync] (0x0100): Principal name is: 
> [VICTORIA$@NAT.C.SDU.DK]
> (Fri Nov  9 11:51:39 2012) [[sssd[ldap_child[4441 
> [ldap_child_get_tgt_sync] (0x0100): Using keytab [default]
> (Fri Nov  9 11:51:39 2012) [[sssd[ldap_child[4441 [pack_buffer] (0x1000): 
> result [0] krberr [0] msgsize [40] msg 
> [FILE:/var/lib/sss/db/ccache_NAT.C.SDU.DK]
> ..
> 
> Sssd_nat.c.sdu.dk.log
> .
> Fri Nov  9 12:07:00 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_account_info] 
> (0x0100): Got request for [4097][1][name=imadatestuser]
> (Fri No

Re: [SSSD-users] Multi-domain logon problem

[Jakub Hrozek]

On Fri, Nov 09, 2012 at 12:57:25PM +0100, ballock wrote:
> Hello,
> 
> I stumbled upon a problem that I believe to be a bug, but perhaps I
> am wrong.
> 
> Basically what happens is that if I have a line in /etc/hosts:
> 127.0.1.1 machine1.europe.example.com machine1
> then I can only log in from europe.example.com domain.
> 
> I reported this as:
> https://fedorahosted.org/sssd/ticket/1633
> but perhaps this is a 'feature'? That sssd resolves the current
> machine domain and only allows to log in from this domain?
> 
> Cheers,
> Ballock

Hi,

it is a bug, not a feature. Thank you for letting us know about the
problem...we just haven't gotten around to fixing it, several issues
were filed today.

You mentioned that you would be able to try and reproduce the problem
with master, too. Would you mind trying that?

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

Re: [SSSD-users] A test repository with SSSD 1.9 for RHEL-6.3

[Jakub Hrozek]

On Fri, Nov 09, 2012 at 03:10:53PM -0500, Dmitri Pal wrote:
> On 11/09/2012 09:01 AM, Simo Sorce wrote:
> > On Fri, 2012-11-09 at 08:58 +0100, Ondrej Valousek wrote:
> >>
> >> On 11/08/2012 06:24 PM, Jakub Hrozek wrote: 
> >>>>> 2. sssd won't work when I specify correct ldap_sasl_authid (see the
> >>>>> example above). This is bad as I might have my krb5.keytab cluttered
> >>>>> with other (possibly not working) keys so I would like to keep the
> >>>>> possibility of specifying the ldap_sasl_authid manually.
> >>> So this is authid that was working with the plain ldap provider but
> >>> dosn't work with ad provider? Can you share logs? 
> >>>
> >>> Have you tried if using this authid works even with 1.9 with the ldap
> >>> provider?
> >>>
> >> looks like the syntax of the ldap_sasl_authid parameter has changed.
> >> Previously (in the 1.8.x version) it accepted form
> >> @, now it only accepts 
> > Can you create a ticket for this ?
> > We shouldn't break existing configurations, and this sound just like a
> > plain bug to me.
> >
> > Simo.
> >
> Can someone very that this is an issue and log a ticket?

Given that it's Friday evening already and the issue might get forgotten
easily over the weekend I created a ticket to investigate the possible
issue:
https://fedorahosted.org/sssd/ticket/1635

Even if it turned out to be a documentation task, if an experienced
user like Ondrej ran into this problem, chances are others will as well.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] FW: startup problem/port 0 not working

[Jakub Hrozek]

On Fri, Nov 09, 2012 at 03:23:55PM -0500, Dmitri Pal wrote:
> On 11/09/2012 07:27 AM, Longina Przybyszewska wrote:
> > Hi again,
> >
> > Here you are all logs after 'getent passwd imadatestuser'
> >
> > root@victoria:/var/log/sssd# cat /etc/sssd/sssd.conf | grep -v ^#
> >
> > [sssd]
> > debug_level = 0x1310
> > config_file_version = 2
> > services = nss, pam
> > domains = nat.c.sdu.dk
> >
> > [nss]
> > filter_groups = root
> > filter_users = root
> >
> > [pam]
> >
> > [domain/nat.c.sdu.dk]
> >
> > debug_level = 10
> >
> > enumerate = False
> > min_id = 1000
> > max_id = 2
> >
> > auth_provider = ad
> > krb5_realm = NAT.C.SDU.DK
> >
> >
> > id_provider = ad
> > access_provider = ad
> > chpass_provider = ad
> > ldap_user_search_base = ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk
> > ldap_user_object_class = person
> >
> >
> > ldap_group_object_class = group
> > ldap_group_search_base = ou=ADGroups,dc=nat,dc=c,dc=sdu,dc=dk
> >
> >
> > ad_server = nat.c.sdu.dk
> > ad_hostname = VICTORIA$@NAT.C.SDU.DK
> > ad_domain = nat.c.sdu.dk
> >
> > ...
> > Krb5_child. Log empty
> > .
> > Sssd-nat.c.sdu.dk.log
> > ..
> > Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] [recreate_ares_channel] 
> > (0x0100): Initializing new c-ares channel (Fri Nov  9 13:06:36 2012) 
> > [sssd[be[nat.c.sdu.dk]]] [resolv_get_family_order] (0x1000): Lookup order: 
> > ipv4_first (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [sysdb_domain_init_internal] (0x0200): DB File for nat.c.sdu.dk: 
> > /var/lib/sss/db/cache_nat.c.sdu.dk.ldb
> > (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_init_connection] 
> > (0x0200): Adding connection 2221550 (Fri Nov  9 13:06:36 2012) 
> > [sssd[be[nat.c.sdu.dk]]] [monitor_common_send_id] (0x0100): Sending ID: 
> > (%BE_nat.c.sdu.dk,1) (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [create_socket_symlink] (0x1000): Symlinking the dbus path 
> > /var/lib/sss/pipes/private/sbus-dp_nat.c.sdu.dk.5678 to a link 
> > /var/lib/sss/pipes/private/s bus-dp_nat.c.sdu.dk (Fri Nov  9 13:06:36 2012) 
> > [sssd[be[nat.c.sdu.dk]]] [load_backend_module] (0x1000): Loading backend 
> > [ad] with path [/usr/lib/x86_64-linux-gnu/sssd/libsss_ad.so].
> > (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] [ad_get_common_options] 
> > (0x0100): Setting domain case-insensitive (Fri Nov  9 13:06:36 2012) 
> > [sssd[be[nat.c.sdu.dk]]] [ad_servers_init] (0x0100): Added failover server 
> > nat.c.sdu.dk (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [ad_set_search_bases] (0x0100): Search base not set. SSSD will attempt to 
> > discover it later, when connecting to the LDAP server.
> > (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [common_parse_search_base] (0x0100): Search base added: 
> > [USER][ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk][SUBTREE][]
> > (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [common_parse_search_base] (0x0100): Search base added: 
> > [GROUP][ou=ADGroups,dc=nat,dc=c,dc=sdu,dc=dk][SUBTREE][]
> > (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] [ad_get_id_options] 
> > (0x0100): Option krb5_realm set to NAT.C.SDU.DK (Fri Nov  9 13:06:36 2012) 
> > [sssd[be[nat.c.sdu.dk]]] [select_principal_from_keytab] (0x0200): trying to 
> > select the most appropriate principal from keytab (Fri Nov  9 13:06:36 
> > 2012) [sssd[be[nat.c.sdu.dk]]] [match_principal] (0x1000): Principal 
> > matched to the sample (*$@NAT.C.SDU.DK).
> > (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [select_principal_from_keytab] (0x0200): Selected primary: VICTORIA$ (Fri 
> > Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [select_principal_from_keytab] (0x0200): Selected realm: NAT.C.SDU.DK (Fri 
> > Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] [ad_get_id_options] 
> > (0x0100): Option ldap_sasl_authid set to VICTORIA$ (Fri Nov  9 13:06:36 
> > 2012) [sssd[be[nat.c.sdu.dk]]] [ad_get_id_options] (0x0100): Option 
> > ldap_sasl_realm set to NAT.C.SDU.DK (Fri Nov  9 13:06:36 2012) 
> > [sssd[be[nat.c.sdu.dk]]] [load_backend_module] (0x1000): Backend [ad] 
> > already loaded.
> > (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] [ad_get_auth_options] 
> > (0x0100): Option krb5_server set to nat.c.sdu.dk (Fri Nov  9 13:06:36 2012) 
> > [sssd[be[nat.c.sdu.dk]]] [ad_get_auth_options] (0x0100): Option krb5_realm 
> > set to NAT.C.SDU.DK (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [check_and_export_lifetime] (0x0200): No lifetime configured.
> > (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [check_and_export_lifetime] (0x0200): No lifetime configured.
> > (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [check_and_export_options] (0x0100): No kpasswd server explicitly 
> > configured, using the KDC or defaults.
> > (Fri Nov  9 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] 
> > [check_and_export_options] (0x0100): ccache is of type FILE (Fri Nov  9 
> > 13:06:36 2012) [sssd[be[nat.c.sdu.dk]]] [load_backend_module] (0x1000): 
> > Ba

Re: [SSSD-users] problems sssd-1.9.2

[Jakub Hrozek]

On Tue, Nov 13, 2012 at 12:44:45PM +, Longina Przybyszewska wrote:
> Hi,
> I try sssd-1.9.2 on Ubuntu-Quantal with ad-provider.
> 
> So far I can login to the desktop with AD identity; 
> Login hangs a bit because of unknown group; 
> 
> What is the best practice  to resolve the group (set up PrimaryGroupId, run  
> idmap)
> 

Sorry, I don't quite understand this problem...are you seeing a
particular group GID not being converted from SID? 

Or are you seeing failures due to the SSSD attempting to convert any of the
"local" groups such as "Domain Users" ?

> The option 'default_shell = /bin/bash'  in sssd.conf  doesn't seem to have
>  effect. 
>  I would expect it being visible In users info:
> 

Into which section in the SSSD did you put the default_shell option? In
1.9.2 it was only supported in the [nss] section, we changed the option
to also take effect in the domain section during 1.9.3 development.

> getent passwd imadatestuser
> imadatestuser:*:332410389:332400513:IMADAtest Testesen:/home/imadatestuser:
> 
> 
> In pam.d/common-session  I added entry for case of nonexistent homedir 
> reference, and shell - so
> ADuser can login.
> 

Do your users have any home directory at all? Could you maybe use the
fallback_homedir or override_homedir directives?

> There is a lot of messages in sssd_nat.c.sdu.dk - for searching principal 
> info for  lightdm in AD -
> Is it correct? Shouldn't be sssd awared  that lightdm is a local service?
> 
> .
> Tue Nov 13 10:29:29 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] 
> (0x4000): Received SBUS method [pamHandler]
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_pam_handler] 
> (0x0100): Got request with the following data
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): command: PAM_OPEN_SESSION
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): domain: nat.c.sdu.dk
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): user: imadatestuser
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): service: lightdm
>   
>  

This is OK, I guess that lightdm is your display manager and there would
be a file such as /etc/pam.d/lightdm on your system? These messages are
just telling that a PAM session was opened for a user who was logging in
wusing the lightdm service.

> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): tty: :0
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): ruser: 
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): rhost: 
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): authtok type: 0
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): authtok size: 0
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): newauthtok type: 0
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): newauthtok size: 0
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): priv: 1
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] 
> (0x0100): cli_pid: 2564
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_pam_handler] 
> (0x0100): Sending result [0][nat.c.sdu.dk]
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): 
> dbus conn: 7063D0
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): 
> Dispatching.
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] 
> (0x4000): Received SBUS method [getDomains]
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_subdomains] 
> (0x2000): Undefined backend target.
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): 
> dbus conn: 7063D0
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): 
> Dispatching.
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] 
> (0x4000): Received SBUS method [getAccountInfo]
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_account_info] 
> (0x0100): Got request for [4099][1][name=lightdm]
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_id_op_connect_step] 
> (0x4000): reusing cached connection
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_initgr_send] 
> (0x4000): Retrieving info for initgroups call
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] 
> [sdap_get_initgr_next_base] (0x0400): Searching for users with base 
> [ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk]
> (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] 
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(sAMAccountName=lightdm)(objectclass=person))][ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk].^
> 
>

Re: [SSSD-users] sss_cache is not working for automount maps

[Jakub Hrozek]

On Tue, Nov 13, 2012 at 05:02:13PM +0100, Ondrej Valousek wrote:
> Hi List,
> 
> Is sss_cache (as of version 1.9.2) supposed to work for automount maps (i.e. 
> -a & -A parameters)?
> It seems to me that it is not working - maps are not reloaded (tcpdump port 
> ldap says nothing)
> Just asking first before submitting a bug report :)
> 
> Thanks,
> Ondrej

It should work. There is no known bug towards that functionality.

Was that functionality working for you previsously?

I suspect I know what's happening - we keep the map and the keys loaded
in memory after the call to setautomtent, chances are we don't release
the object when the sss_cache is called.

Please include sanitized portion of logs from the autofs responder when
you file the bug report. (debug_level = 8 in the [autofs] section).
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] problems sssd-1.9.2

[Jakub Hrozek]

On Tue, Nov 13, 2012 at 03:40:14PM +, Longina Przybyszewska wrote:
> 
> 
> -Original Message-
> From: sssd-users-boun...@lists.fedorahosted.org 
> [mailto:sssd-users-boun...@lists.fedorahosted.org] On Behalf Of Jakub Hrozek
> Sent: 13. november 2012 14:58
> To: sssd-users@lists.fedorahosted.org
> Subject: Re: [SSSD-users] problems sssd-1.9.2
> 
> On Tue, Nov 13, 2012 at 12:44:45PM +, Longina Przybyszewska wrote:
> > Hi,
> > I try sssd-1.9.2 on Ubuntu-Quantal with ad-provider.
> > 
> > So far I can login to the desktop with AD identity; Login hangs a bit 
> > because of unknown group;
> > 
> > What is the best practice  to resolve the group (set up 
> > PrimaryGroupId, run  idmap)
> > 
> 
> Sorry, I don't quite understand this problem...are you seeing a particular 
> group GID not being converted from SID? 
> 
> Or are you seeing failures due to the SSSD attempting to convert any of the 
> "local" groups such as "Domain Users" ?
> 
> I see  messages about groups - why so many at one aduser login?
> ..
> Groups: cannot find name for group ID 332400513
> Groups: cannot find name for group ID 988022561
> Groups: cannot find name for group ID 988803222
> Groups: cannot find name for group ID .
> and tens more...
> 

OK, I suspect you are hitting
https://bugzilla.redhat.com/show_bug.cgi?id=867874 which was resolved
recently as well.

> 
> > The option 'default_shell = /bin/bash'  in sssd.conf  doesn't seem to 
> > have  effect.
> >  I would expect it being visible In users info:
> > 
> 
> Into which section in the SSSD did you put the default_shell option? In
> 1.9.2 it was only supported in the [nss] section, we changed the option to 
> also take effect in the domain section during 1.9.3 development.
> 
> OK - I put it into [domain] 

Right, in 1.9.2 it only works in the [nss] section. It's going to also
work from the [domain] section in 1.9.3

> 
> > getent passwd imadatestuser
> > imadatestuser:*:332410389:332400513:IMADAtest Testesen:/home/imadatestuser:
> > 
> > 
> > In pam.d/common-session  I added entry for case of nonexistent homedir 
> > reference, and shell - so ADuser can login.
> > 
> 
> Do your users have any home directory at all? Could you maybe use the 
> fallback_homedir or override_homedir directives?
> 
> Yes, I do use fallback_homedir in [domain] section and that works. 
> 
> Linux users have homedirs on NFSserver -  auto.home maps are in NIS format.
> 

You might also be interested in the automounter integration, although
I'm not sure that piece of functionality had been backported to Ubuntu
yet. The Ubuntu automounter maintainer would know best.

> Your SSSD is really great piece of software  - so elegant concept ! I love it.
> 

We are really glad to hear this, thank you!
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] RFC: dropping upstream support of RHEL5 starting with 1.10

[Jakub Hrozek]

Hi,

many new features rely on library APIs and features that are only available
in recent versions of SSSD dependencies. As a result, the code often needs
#ifdefs and special branches in order to at least compile or run on RHEL5.

So far we've been doing nightly builds also for RHEL5 and fixing issues
as we were finding them. But recently we are considering dropping support
for RHEL5 -- it is causing some engineering effort and at the same time
the audience is probably very limited. If you are running super-stable
enterprise distribution, chances are you are not all that interested in
the latest and possibly very unstable SSSD version.

The proposal would be to keep building and supporting the 1.9.x branch
for RHEL5 and switch to using RHEL6 as the oldest supported release
starting from the 1.10 upstream version. Of course we would still accept
patches from any potential contributors.

Any objections against the plan?
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] problems sssd-1.9.2

[Jakub Hrozek]

On Thu, Nov 15, 2012 at 09:43:39AM +, Longina Przybyszewska wrote:
> 
> 
> -Original Message-
> From: sssd-users-boun...@lists.fedorahosted.org 
> [mailto:sssd-users-boun...@lists.fedorahosted.org] On Behalf Of Jakub Hrozek
> Sent: 13. november 2012 17:38
> To: sssd-users@lists.fedorahosted.org
> Subject: Re: [SSSD-users] problems sssd-1.9.2
> 
> On Tue, Nov 13, 2012 at 03:40:14PM +, Longina Przybyszewska wrote:
> > 
> > 
> > -Original Message-
> > From: sssd-users-boun...@lists.fedorahosted.org 
> > [mailto:sssd-users-boun...@lists.fedorahosted.org] On Behalf Of Jakub 
> > Hrozek
> > Sent: 13. november 2012 14:58
> > To: sssd-users@lists.fedorahosted.org
> > Subject: Re: [SSSD-users] problems sssd-1.9.2
> > 
> > On Tue, Nov 13, 2012 at 12:44:45PM +, Longina Przybyszewska wrote:
> > > Hi,
> > > I try sssd-1.9.2 on Ubuntu-Quantal with ad-provider.
> 
> 
> You might also be interested in the automounter integration, although I'm not 
> sure that piece of functionality had been backported to Ubuntu yet. The 
> Ubuntu automounter maintainer would know best.
> 
> Oh, yes - how stable is automounter integration in the latest stable SSSD?
> Is I enough to use autofs-5 - or does it need more integration with some SSSD 
> moduls/libraries?

I think the sss support was introduced in autofs 5.0.6, at least in
Fedora. I'm actually not quite sure about autofs upstream. You need to
look for the lookup_sss.so module.

> 
> Until I am lucky to get new packages from Ubuntu maintainers - can I use 
> nsswitch pointing to auto.home maps - would it work with SSSD?

The SSSD integration is provided by the lookup_sss.so module, which is
able to talk to the autofs responder process of the SSSD. If your
distribution doesn't provide that module, you should still be able to
fall back to the LDAP lookups. You just won't be able to leverage the
unified configuration in sssd.conf and caching of the maps.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Howto to accept users with uidnumber or gidnumber equal to 0 ?

[Jakub Hrozek]

On Fri, Nov 30, 2012 at 11:06:26AM +0100, Sumit Bose wrote:
> On Fri, Nov 30, 2012 at 10:29:04AM +0100, Christian Claveleira wrote:
> > Hi,
> > 
> > I'm trying to setup sssd (sssd-1.8.0-32) on CentOS release 6.3.
> > We have some users whose uidnumber or gidnumber is equal to 0 in our LDAP.
> > I set min_id to 0 in the domain section but these users are filtered out :
> > 
> > (Thu Nov 29 17:23:02 2012) [sssd[be[LDAP]]] [sdap_save_user] (0x0040): User 
> > [root-rdm] filtered out! (id out of range)
> > (Thu Nov 29 17:23:02 2012) [sssd[be[LDAP]]] [sdap_save_user] (0x0040): 
> > Failed to save user [root-rdm]
> > (Thu Nov 29 17:23:02 2012) [sssd[be[LDAP]]] [sdap_save_users] (0x0040): 
> > Failed to store user 0. Ignoring.
> > 
> > Am I missing something ?
> 
> UIDs and GIDs equal to 0 are always filtered out for security reasons
> independent of the settings of min_id. I think the sssd.conf man page is
> not very clear about this, maybe would should add a paragraph about it.
> 
> HTH

I agree:
https://fedorahosted.org/sssd/ticket/1681
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] Announcing the release of SSSD 1.9.3

[Jakub Hrozek]

re always returns System Error
https://fedorahosted.org/sssd/ticket/1638
password expiry warning message doesn't appear during auth
https://fedorahosted.org/sssd/ticket/1640
"defaults" entry ignored
https://fedorahosted.org/sssd/ticket/1647
LDAP provider fails to save empty groups
https://fedorahosted.org/sssd/ticket/1649
ldap_connection_expire_timeout doesn't expire ldap connections
https://fedorahosted.org/sssd/ticket/1650
Wrong variable check in sudosrv_parse_query_send
https://fedorahosted.org/sssd/ticket/1651
Unchecked return value from waitpid()
https://fedorahosted.org/sssd/ticket/1652
updating top-level group does not reflect ghost members correctly
https://fedorahosted.org/sssd/ticket/1657
SIGSEGV in IPA provider when ldap_sasl_authid is not set
https://fedorahosted.org/sssd/ticket/1658
ipa password auth failing for user principal name when shorter than IPA 
Realm name
https://fedorahosted.org/sssd/ticket/1661
Allow backward compatible regex for domain / realm search in sssd 1.9
https://fedorahosted.org/sssd/ticket/1668
delete operation is not implemented for ghost users
https://fedorahosted.org/sssd/ticket/1669
sssd hangs at startup with broken configurations
https://fedorahosted.org/sssd/ticket/1671
mmap cache needs update after db changes
https://fedorahosted.org/sssd/ticket/1674
Explicit null dereferenced
https://fedorahosted.org/sssd/ticket/1683
arithmetic bug in the SSSD causes netgroup midpoint refresh to be always 
set to 10 seconds
https://fedorahosted.org/sssd/ticket/1684
Dereference after null check in sss_idmap_sid_to_unix
https://fedorahosted.org/sssd/ticket/1686
sssd crashes during start if id_provider is not mentioned
https://fedorahosted.org/sssd/ticket/1688
sssd_sudo prints wrong debug message when notBefore or notAfter attribute 
is missing
https://fedorahosted.org/sssd/ticket/1694
Incorrect synchronization in mmap cache
https://fedorahosted.org/sssd/ticket/1695
user is not removed from group membership during initgroups

== Packaging Changes ==
* The sss_cache has been moved from sss-tools subpackage to the main sssd 
package
* The upstream RPM uses a systemd unit file by default, rather than a SystemV 
init script
* Several rpmlint warnings have been fixed in the upstream spec file

== Detailed Changelog ==
Ariel O. Barria (1):
  * Monitor quit when not exists no process no stops

Jakub Hrozek (42):
  * Updating the version for the 1.9.3 release
  * LDAP: Check validity of naming_context
  * Allow setting the default_shell option per-domain as well
  * KRB5: Return error when principal selection fails
  * Free the internal DP request
  * LDAP: Fix off-by-one error when saving ghost users
  * Monitor: read the correct SIGKILL timeout for providers, too
  * PAM: Do not leak fd after SELinux context file is written
  * Do not always return PAM_SYSTEM_ERR when offline krb5 authentication 
fails
  * KRB5: Rename variable to avoid shadowing a global declaration
  * Only build extract_and_send_pac on platforms that support it
  * Include the auth_utils.h header in the distribution
  * SYSDB: Do not touch the member attribute during conversion to ghost 
users
  * Provide AM_COND_IF-combatible implementation for old automake systems
  * LDAP: Expire even non authenticated connections
  * SUDO: Fix wrong variable check
  * SERVER: Check the return value of waitpid
  * LDAP: Allocate the temporary context on NULL, not memctx
  * LDAP: Fix saving empty groups
  * LDAP: use the correct memory context
  * LDAP: Refactor saving ghost users
  * Restart services with a delay in case they are restarted too often
  * MAN: document the ldap_sasl_realm option
  * LDAP: Provide a common sdap_set_sasl_options init function
  * LDAP: Checking the principal should not be considered fatal
  * LDAP: Make it possible to use full principal in ldap_sasl_authid again
  * SYSDB: Use the add_string convenience functions for managing ghost user 
attribute
  * LDAP: Only convert direct parents' ghost attribute to member
  * MONITOR: Fix off-by-one error in add_string_to_list
  * Handle compiling FQDN regular expression with old pcre gracefully
  * MEMBEROF: Do not add the ghost attribute to self
  * TESTS: Test ghosts users in the RFC2307 schema
  * NSS: Fix netgroup midpoint cache refresh
  * LDAP: Continue adjusting group membership even if there is nothing to 
add
  * MEMBEROF: Implement delete operation for ghost users
  * MEMBEROF: split processing the member modify into a separate function
  * MEMBEROF: Split the del ghost attribute op into a reusable function
  * MEMBEROF: Split the add ghost operation into a separate function
  * MEMBEROF: Implement the modify operation for ghost users
  * MEMBEROF: Keep inherited ghost users 

Re: [SSSD-users] A test repository with SSSD 1.9 for RHEL-6.3

[Jakub Hrozek]

On Thu, Oct 18, 2012 at 11:23:53AM +0200, Jakub Hrozek wrote:
> Hi,
> 
> even though RHEL-6.4 is still brewing, I think there might be some
> interest in trying out the 1.9.x series of the SSSD on RHEL-6.3.
> 
> So I went ahead and built the SSSD 1.9.2 in a RHEL-6.3 buildroot:
> http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/
> 
> The NVR of these test packages will be lower than those in 6.4 to keep
> the upgrade path clean. The only missing functionality is the PAC
> responder, which means this SSSD version won't be able to work with
> an AD domain that is in a trust relationship with an IPA 3.x domain. I
> had to disable the PAC responder as it requires Kerberos 1.10.
> 
> Because some new functionality required tweaking the SELinux policy, you
> will encounter AVC denials when the new fast cache is accessed. That
> said, my quick smoke testing went fine and we will be glad to hear test
> results or bug reports.
> 
> Using the repository comes with a warning - this is NOT an official Red
> Hat supported repository. The packages have NOT gone through formal QA. If
> it breaks your RHEL-6.3 installation, you get to keep the pieces.
> 
> This is the repo configuration I used:
> --
> [sssd-1.9-RHEL6.3]
> name=SSSD 1.9.x built for latest stable RHEL
> baseurl=http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/$basearch/
> enabled=1
> skip_if_unavailable=1
> gpgcheck=0
> 
> [sssd-1.9-RHEL6.3-source]
> name=SSSD 1.9.x built for latest stable RHEL - Source
> baseurl=http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/SRPMS
> enabled=0
> skip_if_unavailable=1
> gpgcheck=0
> --
> 
> Happy testing!

Hi,

First and foremost I wanted to thank all the users who have submitted their
bug reports, test results or any other form of feedback. We've managed
to identify several critical bugs in the 1.9.2 release we haven't seen
during our testing, in particular related to database upgrade or nested
group memberships. Thank you!

I have refreshed the repository with bits that are equivalent to
upstream 1.9.3 release and are quite close to what RHEL6.4 would be
shipping with.

Because RHEL6.4 is going to ship 1.9.2 + patches, we needed to maintain
a clean upgrade path from this repository to 6.4 final. So we chose
quite nonstandard release tag that contains upstream_1_9_3 to make it
clear you're running upstream 1.9.3 just with a funny name.

Upgrading from the previous builds in the same repo should be smooth as
well.

Fixing the nested group memberships required a little more processing
when saving the groups. So I wanted to ask the users who have reported
performance enhancements as compared with 1.8 to kindly check if the
new packages are still doing good performance wise.

Using the repository comes with a warning - this is NOT an official Red
Hat supported repository. The packages have NOT gone through formal QA.
Please proceed with caution.

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

Re: [SSSD-users] [SSSD] A test repository with SSSD 1.9 for RHEL-6.3

[Jakub Hrozek]

On Mon, Dec 10, 2012 at 02:16:50PM +0100, Jakub Hrozek wrote:
> I have refreshed the repository with bits that are equivalent to
> upstream 1.9.3 release and are quite close to what RHEL6.4 would be
> shipping with.

I refreshed the repo again, the previous packages in uploaded this
morning had a packaging bug that caused the 1.9.2 tarball to be
included. I didn't realize at first that the %setup macro looks for
%{name}-%{version} by default and I forgot to override that with -n.

I fixed the packages (and verified that it's really 1.9.3 code this
time) and uploaded them to the repo. Please upgrade to
1.9.2-5.upstream_1_9_3.el6_3 or later.

Sorry for the inconvenience.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] CentOS 6.2 Kerberos Authentication Issue

[Jakub Hrozek]

On Wed, Dec 12, 2012 at 12:26:11PM -0200, Hugo Lima wrote:
> Hi guys,
> 
> i'm facing some trouble when i do ssh to a CentOS 6.2 machine using AD
> authentication. I am using SSSD, with krb5.conf and sssd.conf, well
> configured (tested in other OS, like RHEL). The account information comes
> when i make id or getent passwd. Seems something with ssh and kerberos
> troubles.
> 
> I have already set 777 permission on /tmp and disabled SElinux, like logs
> indicates permission issue, but didn't get sucess. Have tried an update but
> in vain too.
> 
> The krb5.child log is:
> 
> 
> 
> 
> Can anyone help me?
> 
> Thanks,
> 
> Hugo Lima.

Hi Hugo,
It seems you forgot to paste or attach the krb5 child log?
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] [SSSD] A test repository with SSSD 1.9 for RHEL-6.3

[Jakub Hrozek]

On Mon, Dec 10, 2012 at 05:58:09PM +0100, Jakub Hrozek wrote:
> On Mon, Dec 10, 2012 at 02:16:50PM +0100, Jakub Hrozek wrote:
> > I have refreshed the repository with bits that are equivalent to
> > upstream 1.9.3 release and are quite close to what RHEL6.4 would be
> > shipping with.
> 
> I refreshed the repo again, the previous packages in uploaded this
> morning had a packaging bug that caused the 1.9.2 tarball to be
> included. I didn't realize at first that the %setup macro looks for
> %{name}-%{version} by default and I forgot to override that with -n.
> 
> I fixed the packages (and verified that it's really 1.9.3 code this
> time) and uploaded them to the repo. Please upgrade to
> 1.9.2-5.upstream_1_9_3.el6_3 or later.
> 
> Sorry for the inconvenience.

One more refresh - I've built 1.9.2-5.upstream_1_9_3.el6_3 that includes
all the fixes since 1.9.3, in particular the memory leaks and nss crash
John Hodrien reported and the ldap_sasl_authid regression reported by
Ondrej Valousek. We plan on including the additional fixes as per the
1.9.4 milestone in the SSSD Trac.

Once again, thank you very much for testing.

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

Re: [SSSD-users] Connection to LDAP server not working

[Jakub Hrozek]

On Wed, Jan 02, 2013 at 10:52:00AM +0100, Marco Pizzoli wrote:
> Hi guys,
> I'm currently not able to get sssd working in connecting to an AD server as
> a pure LDAPS server.
> 
> I'm succeeding in connecting with a simple bind, but eventually I can't get
> sssd downloading any data. It ends with a
>  Search result: Operations error(1), 04DC: LdapErr: DSID-0C0906E8,
> comment: In order to perform this operation a successful bind must be
> completed on the connection., data 0, v1db1
> 
> By using ldapsearch (pointing to the same ldaps url) I can execute the same
> search obtaining (correctly) 1 user.
> Honestly, I don't know what could be the problem... Any hint on a
> particular configuration directive to check?
> 
> Full log following.
> I'm using sssd-1.8.0-32.el6.x86_64 on RHEL6.3
> 
> Thanks in advance
> Marco

From the logs it seems that you are binding as "CN=baubau,OU=Service
Accounts,DC=testpippo,DC=local" but not using any bind password. Is this
the same setting that works for you with ldapsearch?
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Connection to LDAP server not working

[Jakub Hrozek]

On Wed, Jan 02, 2013 at 01:38:12PM +0100, Marco Pizzoli wrote:
> Hi Jakub,
> 
> On Wed, Jan 2, 2013 at 1:13 PM, Jakub Hrozek  wrote:
> 
> > On Wed, Jan 02, 2013 at 10:52:00AM +0100, Marco Pizzoli wrote:
> > > Hi guys,
> > > I'm currently not able to get sssd working in connecting to an AD server
> > as
> > > a pure LDAPS server.
> > >
> > > I'm succeeding in connecting with a simple bind, but eventually I can't
> > get
> > > sssd downloading any data. It ends with a
> > >  Search result: Operations error(1), 04DC: LdapErr: DSID-0C0906E8,
> > > comment: In order to perform this operation a successful bind must be
> > > completed on the connection., data 0, v1db1
> > >
> > > By using ldapsearch (pointing to the same ldaps url) I can execute the
> > same
> > > search obtaining (correctly) 1 user.
> > > Honestly, I don't know what could be the problem... Any hint on a
> > > particular configuration directive to check?
> > >
> > > Full log following.
> > > I'm using sssd-1.8.0-32.el6.x86_64 on RHEL6.3
> > >
> > > Thanks in advance
> > > Marco
> >
> > From the logs it seems that you are binding as "CN=baubau,OU=Service
> > Accounts,DC=testpippo,DC=local" but not using any bind password. Is this
> > the same setting that works for you with ldapsearch?
> >
> 
> Shame on me...
> In my sssd.conf I had:
> ldap_default_authok_type = password
> ldap_default_authok = my_password
> 
> Instead of
> ldap_default_auth*t*ok_type = password
> ldap_default_auth*t*ok = my_password
> 
> Now I managed to have it working. I admit I didn't noticed it before your
> hint.
> 
> I just looked back at the logs, but I don't notice any hint about my error.
> Should the sssd put a warning about a unknown/wrong directive?
> 

This is how I found out:

(Wed Jan  2 09:20:26 2013) [sssd[be[TESTpippo.local]]] [dp_get_options]
(0x0400): Option ldap_default_bind_dn has value CN=baubau,OU=Service
Accounts,DC=testpippo,DC=local
(Wed Jan  2 09:20:26 2013) [sssd[be[TESTpippo.local]]] [dp_get_options]
(0x0400): Option ldap_default_authtok_type has value password
(Wed Jan  2 09:20:26 2013) [sssd[be[TESTpippo.local]]] [dp_get_options]
(0x0400): Option ldap_default_authtok has no binary value.
  ^ 
"No binary value" pretty much says "unset".

> Thanks a lot for your help!
> Marco
> 
> @Ondrej: I'm sorry, but in this very case I couldn't share my configuration
> before the approval of a currently-on-holiday manager. I would have done it
> otherwise. Thanks anyway.
> 
> 
> > ___
> > 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

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

Re: [SSSD-users] Problem limiting access to Users in Certain AD groups.

[Jakub Hrozek]

On Mon, Jan 14, 2013 at 08:37:56PM +, Daniel Laird wrote:
> I am stuck with Ubuntu 10.04 (no chance of upgrading our servers).
> This means I am currently running SSSD 1.0.5.

This is a very, very old version of SSSD. It hasn't been supported in
ages.

> 
> I want to limit which users can login.
> In later versions I believe I would use 
> 'ldap_access_filter'
> 

Does that version have the "simple" access provider (man sssd-simple).
If so, you could use that one.

> This would allow only users in the specified groups to login.
> 
> Given my limitation on the version of SSSD can anyone help me achieve the 
> same or is it not possible?
> 
> I am a bit scared of rebuilding newer versions of SSSD.
> 

I would really urge you to upgrade. I'm CC-ing Timo Aaltonen, the Ubuntu
SSSD maintainer. 

Timo, do you have maybe any PPA for 10.04 with more recent SSSD
versions?

> Hope you can help
> Dan
> 
> Sent from my ASUS Eee Pad
> ___
> 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

Re: [SSSD-users] Problem limiting access to Users in Certain AD groups.

[Jakub Hrozek]

On Mon, Jan 14, 2013 at 04:41:42PM -0500, Stephen Gallagher wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Mon 14 Jan 2013 04:28:57 PM EST, Jakub Hrozek wrote:
> > On Mon, Jan 14, 2013 at 08:37:56PM +, Daniel Laird wrote:
> >> I am stuck with Ubuntu 10.04 (no chance of upgrading our servers).
> >> This means I am currently running SSSD 1.0.5.
> >
> > This is a very, very old version of SSSD. It hasn't been supported in
> > ages.
> >
> >>
> >> I want to limit which users can login.
> >> In later versions I believe I would use
> >> 'ldap_access_filter'
> >>
> >
> > Does that version have the "simple" access provider (man sssd-simple).
> > If so, you could use that one.
> >
> >> This would allow only users in the specified groups to login.
> >>
> >> Given my limitation on the version of SSSD can anyone help me achieve the 
> >> same or is it not possible?
> >>
> >> I am a bit scared of rebuilding newer versions of SSSD.
> >>
> >
> > I would really urge you to upgrade. I'm CC-ing Timo Aaltonen, the Ubuntu
> > SSSD maintainer.
> >
> > Timo, do you have maybe any PPA for 10.04 with more recent SSSD
> > versions?
> >
> 
> 
> 
> SSSD was approved for a standing Micro Release Exception on January
> 8th[1], meaning that it's now on the list of packages that Ubuntu can
> opt to upgrade within a stable release. My understanding is that there
> are plans to backport SSSD 1.8 at least to the currently-supported
> Ubuntu releases, though Timo will have to confirm that for me (I'm only
> going from hearsay).
> 
> [1] https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions

Ah, thank you, I was wondering what MRE stands for when I was skimming
through the Ubuntu bug reports lately :-)
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] A security bug in SSSD 1.8 and 1.9 (CVE-2013-0220)

[Jakub Hrozek]

= A security bug in SSSD 1.8 and 1.9 ===
=
= Subject:  out-of-bounds reads in autofs and ssh responder
=
= CVE ID#:  CVE-2013-0220
=
= Summary:  Multiple out-of-bounds buffer read flaws were found in
=   the way the autofs and ssh responders of the SSSD
=   performed the parsing of input packet values. An attacker
=   could crash the autofs and ssh responders with the use
=   of a carefully crafted packet written to the responder
=   sockets.
=
=
= Impact:   low
=
= Acknowledgements: The bug was found by Florian Weimer of the Red Hat
=   Product Security team
=
= Affects default
=  configuration:   yes (as generated by ipa-client-install)
=
= Introduced with:  1.8.0
=
===
 
 DESCRIPTION 
 
SSSD versions 1.8.0 through 1.9.3 are vulnerable to a security bug.
 
The functions that parse the incoming data packet from client applications
in both the ssh and autofs responders do not check the string lengths against
the packet length correctly. An attacker could exploit the bug and crash
the autofs or the ssh responder with the use of a specially crafted packet
sent to the responder sockets, causing a temporary denial of service.
 
If you are not using the autofs or SSH integration, you can disable the
vulnerable responders by removing "ssh" or "autofs" respectively from the
list of services configured in the [sssd] section of the SSSD config file.
 
The default configuration of a client of FreeIPA - as generated by
ipa-client-install - is affected because the ssh responder is enabled
by default.
 
The fix will be delivered as part of the upcoming 1.9.4 release. There won't
be a separate 1.9 security release as the 1.9.4 version will be released later
this week. The flaw will be fixed in a separate release for the 1.8 and 1.5 LTM
releases as well.
 
The bug is being tracked in the following Red Hat Bugzilla report:
https://bugzilla.redhat.com/show_bug.cgi?id=884601
 
 PATCH AVAILABILITY 
 
The patch is available at:
http://git.fedorahosted.org/cgit/sssd.git/patch/?id=2bd514cfde1938b1e245af11c9b548d58d49b325
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] A security bug in SSSD (CVE-2013-0219)

[Jakub Hrozek]

 A security bug in SSSD ===
=
= Subject:  TOCTOU race conditions when creating or removing home
=   directories for users in local domain
=
= CVE ID#:  CVE-2013-0219
=
= Summary:  A TOCTOU (time-of-check, time-of-use) race condition was 
found
=   in the way SSSD performed copying and removal of home
=   directory trees. 
=
=
= Impact:   low
=
= Acknowledgements: The bug was found by Florian Weimer of the Red Hat
=   Product Security Team
=
= Affects default
=  configuration:   no
=
= Introduced with:  0.7.0
=
===

 DESCRIPTION 

SSSD versions 0.7.0 through 1.9.3 (inclusive) are vulnerable to a security bug.

The removal of a home directory is sensitive to concurrent modification of the
directory tree being removed and can unlink files outside the directory tree.
When removing a home directory, if another process is modifying that directory
at the same time, it becomes possible for the SSSD to unlink files that are
outside the directory tree.

When creating a home directory, the destination tree can be modified in various
ways while it is being constructed because directory permissions are set before
populating the directory. This can lead to file creation and permission changes
outside the target directory tree using hard links.

The fix will be delivered as part of the upcoming 1.9.4 release. There
won't be a separate 1.9 security release as the 1.9.4 version will be
released later this week. The flaw will be fixed in a separate release
for the 1.8 and 1.5 LTM release branches as well.

The bug is being tracked in the following Red Hat Bugzilla report:
https://bugzilla.redhat.com/show_bug.cgi?id=884254

 WORKAROUND 

These vulnerabilities are present only while creating or removing home
directories, so until patched packages are available, you can simply
refrain from performing these actions.

 PATCH AVAILABILITY 

The patches are available at:
http://git.fedorahosted.org/cgit/sssd.git/patch/?id=94cbf1cfb0f88c967f1fb0a4cf23723148868e4a
http://git.fedorahosted.org/cgit/sssd.git/patch/?id=020bf88fd1c5bdac8fc671b37c7118f5378c7047
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] SSSD over slow or dropping link

[Jakub Hrozek]

On Wed, Jan 23, 2013 at 02:55:18PM +0100, Bolesław Tokarski wrote:
> Hello,
> 
> I am having a problem where a user is trying to authenticate to our
> European servers while sitting in our Asian office where the link is
> not of the best quality.
> 
> What he is experiencing is a number of failed authentication attempts.
> 
> SSSD version 1.8.5 from Timo Aaltonen's PPA running on Ubuntu 12.04.
> 
> auth.log says:
> sudo: pam_sss(sudo:auth): Request to sssd failed. Broken pipe
> sssd.log says:
> [sssd] [monitor_quit] (0x0010): Monitor received Terminated:
> terminating children

"Broken Pipe" could indicate a segfault, can you check syslog for any
signs of an SSSD component crashing?

If there's nothing of interest, can you raise the debug level
(put debug_level=N where N is 7 or higher into the [pam] and [domain]
sections of SSSD and restart the SSSD) and attach the logs?
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Problems with Kerberos authentication: Cannot find KDC for requested realm

[Jakub Hrozek]

On Sun, Jan 27, 2013 at 02:23:03PM -0800, C. S. wrote:
> Hi folks,
> 
> Any help here would be appreciated, I don't seem to see what the issue is.
> I can login using kinit just fine,

Right, kinit bypasses the PAM stacks and talks directly to the libkrb5
and the kdc.

> but sssd fails when using ssh. It seems
> like it has something to do with the files in /var/lib/sss/pubconf going
> missing, which causes sssd-krb5 to fail with: Cannot find KDC for requested
> realm.

Yes, I think so too, but what puzzles me is that resolving went OK, then the
kdcinfo files are written. Unfortunately there is no debug output unless
there is an error, so we can't see the realm etc.. The "No such file or
directory" errors indicate that the krb5info files are indeed missing.

Are there perhaps any AVC denials when the SSSD is attempting to write
the kdcinfo files?

Are you sure there is no typo in the realm name? Can you also kinit on the
client machine, in other words, if you were testing by ssh testuser@testhost,
can you kinit on testhost? What also seems strange to me is that if krb5.conf
was configured correctly on the client machine, then I would expect the
krb5 child process to use the KDC info from the krb5.conf file..by the
time we reach the child process, it's mostly standard krb5 library calls.

> 
> This is CentOS 6, sssd-1.8.0-32.el6.x86_64.
> 
> e.g. kinit logins works:
> [testuser@test01 ~]$ kinit
> Password for testu...@myrealm.com:
> Warning: Your password will expire in 41 days on Sun Mar 10 19:01:44 2013
> [testuser@test01 ~]$ klist
> Ticket cache: FILE:/tmp/krb5cc_501
> Default principal: testu...@myrealm.com
> 
> Valid starting ExpiresService principal
> 01/27/13 22:13:00  01/28/13 08:13:00  krbtgt/myrealm@myrealm.com
> renew until 02/03/13 22:12:53
> [testuser@test01 ~]$
> 
> 
> But over ssh:
> 
> /var/log/secure:
> Jan 27 21:57:03 test1 sshd[2882]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.74.34.39
>  user=testuser
> Jan 27 21:57:03 test1 sshd[2882]: pam_sss(sshd:auth): system info: [Cannot
> find KDC for requested realm]
> Jan 27 21:57:03 test1 sshd[2882]: pam_sss(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.74.34.39
> user=testuser
> Jan 27 21:57:03 test1 sshd[2882]: pam_sss(sshd:auth): received for user
> testuser: 4 (System error)
> Jan 27 21:57:05 test1 sshd[2882]: Failed password for testuser from
> 10.74.34.39 port 55143 ssh2
> Jan 27 21:57:11 test1 sshd[2883]: Connection closed by 10.74.34.39
> 
> sssd -i -d9 + SSSD_KRB5_LOCATOR_DEBUG=1 output:

Thank you for providing the detailed debug logs.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] Plan for sssd-1.8.6

[Jakub Hrozek]

Hi,

the recent security issue means we need to release a 1.8.6 LTM release
upstream as well.

I plan on releasing 1.8.6 with fixes listed below. Does the list makes
sense for everybody? Would you like to add some fixes that went upstream
but may not be fixed in your distribution or release you are using?

Please respond by tomorrow, I'll tag and release 1.8.6 then.

The tentative list of fixes, tickets they fixed (if any) and commit
hashes from the sssd-1-9 branch (as backporting from master might be
challenging already) is below:

* security fix for CVE-2013-2019
  - https://fedorahosted.org/sssd/ticket/1782
  - sssd-1-9: e864d914a44a37016736554e9257c06b18c57d37
  3843b284cd3e8f88327772ebebc7249990fd87b9
  5c17895a272b06897608d951ea4e60c539138208

* security fix for CVE-2013-2020
  - https://fedorahosted.org/sssd/ticket/1781
  - sssd-1-9: 30e2585dd46b62aa3a4abdf6de3f40a20e1743ab

* Handle empty namingContexts values safely - was affecting Novell eDirectory
  users
  - https://fedorahosted.org/sssd/ticket/1542
  - sssd-1-9: 3f5953b0cd6ad826141c62dd239efc675b351689

* sssd_pam: Cleanup requests cache on sbus reconect
  - This bug was causing the infamous "Timer Expired" errors on reconnect
  - https://fedorahosted.org/sssd/ticket/1655
  - sssd-1-9: 23669fdf7afd1f0b427f98eb20a760101fb80300

* Do not always return PAM_SYSTEM_ERR when offline krb5 authentication fails
   - The backport was explicitly requested by a SuSE user
   - sssd-1-9: 16e0b00c9f6444f058304f669b3a4b18ed751a52

* Free the internal DP request
   - This bug was causing slow and steady memory growth of responders
   - sssd-1-9: ff73778464f56c51716140b69ab29f101c036603

* NSS: Fix netgroup midpoint cache refresh
   - The netgroup midpoint refresh didn't work as advertized
   - https://fedorahosted.org/sssd/ticket/1683
   - sssd-1-9: 83c5a0123f8d473d46091ee0d41a9ed019c78b6c

* responder_dp: Add timeout to side requets
   - A general robustness fix, our QE hit the problem, too while testing
 6.4
   - https://fedorahosted.org/sssd/ticket/1717
   - sssd-1-9: dd85581b726d7db264348ae27d77c4615b7f79d0

* Restart services with a delay in case they are restarted too often
- We've seen several users hit this problem in production
- https://fedorahosted.org/sssd/ticket/1528
- sssd-1-9: 3c922410f0b92a9b8556e28ff5d46ee7a59709c6
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] Announcing SSSD 1.9.4

[Jakub Hrozek]

hosted.org/sssd/ticket/1708
sssd components seem to mishandle sighup
https://fedorahosted.org/sssd/ticket/1710
man sssd-sudo has wrong title
https://fedorahosted.org/sssd/ticket/1714
user id lookup fails for case sensitive users using proxy provider
https://fedorahosted.org/sssd/ticket/1716
Make functions manipulating with mmap cache more defensive
https://fedorahosted.org/sssd/ticket/1717
Limit requests coalescing in time
https://fedorahosted.org/sssd/ticket/1722
crash in memory cache
https://fedorahosted.org/sssd/ticket/1724
Explicit null dereferenced
https://fedorahosted.org/sssd/ticket/1727
AD provider: getgrgid removes nested group memberships
https://fedorahosted.org/sssd/ticket/1728
Failure in memberof can lead to failed database update
https://fedorahosted.org/sssd/ticket/1730
MEmory leak in new memcache initgr cleanup function
https://fedorahosted.org/sssd/ticket/1731
krb5 ticket renewal does not read the renewable tickets from cache
https://fedorahosted.org/sssd/ticket/1732
clarify the disadvantages of enumeration in sssd.conf
https://fedorahosted.org/sssd/ticket/1735
Failover to krb5_backup_kpasswd doesn't work
https://fedorahosted.org/sssd/ticket/1736
Smart refresh doesn't notice "defaults" addition with OpenLDAP
https://fedorahosted.org/sssd/ticket/1740
Incorrect principal searched for in keytab
https://fedorahosted.org/sssd/ticket/1754
wrong filter for autofs maps in sss_cache
https://fedorahosted.org/sssd/ticket/1757
memory cache is not updated after user is deleted from ldb cache
https://fedorahosted.org/sssd/ticket/1758
sssd fails to update to changes on autofs maps
https://fedorahosted.org/sssd/ticket/1760
Failover to ldap_chpass_backup_uri doesn't work
https://fedorahosted.org/sssd/ticket/1761
sssd_be crashes looking up members with groups outside the nesting limit
https://fedorahosted.org/sssd/ticket/1764
Modifications using sss_usermod tool are not reflected in memory cache
https://fedorahosted.org/sssd/ticket/1770
ipa-client-automount: autofs failed in s390x and ppc64 platform
https://fedorahosted.org/sssd/ticket/1773
SSSD should warn when pam_pwd_expiration_warning value is higher than
passwordWarning LDAP attribute.
https://fedorahosted.org/sssd/ticket/1775
local provider: All member users are not returned on looking up top
level parent group.
https://fedorahosted.org/sssd/ticket/1779
Rule mismatch isn't noticed before smart refresh on ppc64 and s390x
https://fedorahosted.org/sssd/ticket/1781
sssd: Out-of-bounds read flaws in autofs and ssh services responders
https://fedorahosted.org/sssd/ticket/1782
TOCTOU race conditions by copying and removing directory trees
https://fedorahosted.org/sssd/ticket/1783
Group lookup fails and takes ~60s to return to shell if member dn
is incorrect
https://fedorahosted.org/sssd/ticket/1787
reset the release in upstream spec before releasing 1.9.4

== Detailed Changelog ==
Jakub Hrozek (47):
*  Updating the version for the 1.9.4 release
*  SUDO: strdup the input variable
*  PAC: check the return value of diff_git_lists
*  SYSDB: Move misplaced assignment
*  LDAP: remove dead assignment
*  MEMBEROF: Fix copy-n-paste error
*  NSS: Fix the error handler in sss_mc_create_file
*  SYSDB: More debugging during the conversion to ghost users
*  MAN: Fix the title of sssd-sudo
*  MEMBEROF: silence compilation warnings
*  Set cloexec flag for log files
*  RESOLV: Do not steal the resulting hostent on error
*  SYSDB: fix copy-n-paste error
*  SYSDB: Add API to invalidate all map objects
*  DP: invalidate all cached maps if a request for auto.master comes in
*  AUTOFS: allow removing entries from hash table
*  AUTOFS: remove all maps from hash if request for auto.master comes in
*  RESPONDERS: Create a common file with service names and versions
*  AUTOFS: Clear enum cache if a request comes in from the sss_cache
*  Add responder_sbus.h to noinst_HEADERS
*  Free resources if fileno failed
*  Search for SHORTNAME$@REALM instead of fqdn$@REALM by default
*  Potential resource leak in sss_nss_mc_get_record
*  SYSDB: Remove duplicate selinux defines
*  SYSDB: Split a function to read all SELinux maps
*  SELINUX: Process maps even when offline
*  IPA: Rename IPA_CONFIG_SELINUX_DEFAULT_MAP
*  AD: replace GID/UID, do not add another one
*  AD: Add user as a direct member of his primary group
*  TOOLS: move memcache related functions to tools_mc_utils.c
*  TOOLS: Split querying nss responder into a separate function
*  TOOLS: Provide a convenience function to refresh a list of groups
*  TOOLS: Refresh memcache after changes to local users and groups
*  LDAP: avoid complex realloc logic in save_rfc2307bis_group_memberships
*  autofs: Use SAFEALIGN_SET_UINT32 instead of SAFEALIGN_COP

Re: [SSSD-users] Problems with Kerberos authentication: Cannot find KDC for requested realm

[Jakub Hrozek]

On Mon, Jan 28, 2013 at 05:34:33PM -0800, C. S. wrote:
> Well, I had to resort adding a DEBUG() line to get_and_save_tgt() to print
> out the realm and princ, and it turned out there was a typo on the UPN in
> my Samba 4 directory entry for the user. I sort of expected it to be
> something stupid.  On that note, do you have any suggestions on where more
> debugging could be added? If I have the cycles I was thinking of submitting
> a patch to make these issues easier to figure out.
> 
> Thanks!
> 
> cs

We've actually added quite some new DEBUG messages to both the Kerberos
and LDAP child processes during 1.9 development, can you check if the one
you needed is perhaps already there?

http://git.fedorahosted.org/cgit/sssd.git/tree/src/providers/krb5/krb5_child.c

http://git.fedorahosted.org/cgit/sssd.git/tree/src/providers/ldap/ldap_child.c

If not, a patch would be welcome!
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] Announcing SSSD 1.8.6

[Jakub Hrozek]

=== SSSD 1.8.6 ===

The SSSD team is proud to announce the bugfix release of the System
Security Services Daemon version 1.8.6.

As always, the source is available from https://fedorahosted.org/sssd

RPM packages will be made available for Fedora shortly, this time for
F-16 and F-17 (before F-17 rebases to 1.9.4)

== Feedback ==

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

== Highlights ==
* A security bug assigned CVE-2013-0219 was fixed - TOCTOU race conditions
  when creating or removing home directories for users in local domain
* A security bug assigned CVE-2013-0220 was fixed - out-of-bounds reads
  in autofs and ssh responder
* Handle servers that return an empty string as the value of namingContext,
  in particular Novell eDirectory
* The netgroup midpoint cache refresh works as documented in the manual page
* The sssd_pam responder processes pending requests after reconnect 

== Tickets Fixed ==
* https://fedorahosted.org/sssd/ticket/1542 
  User authentication using LDAP doesn't work
* https://fedorahosted.org/sssd/ticket/1581
  sssd_be crashes while looking up users
* https://fedorahosted.org/sssd/ticket/1717
  Limit requests coalescing in time
* https://fedorahosted.org/sssd/ticket/1683
  arithmetic bug in the SSSD causes netgroup midpoint refresh to be always
  set to 10 seconds
* https://fedorahosted.org/sssd/ticket/1655
  Login fails - sssd_be module polling fd indefinitely and gets killed
* https://fedorahosted.org/sssd/ticket/1781
  sssd: Out-of-bounds read flaws in autofs and ssh services responders
* https://fedorahosted.org/sssd/ticket/1528
  SSSD_NSS failure to gracefully restart after sbus failure
* https://fedorahosted.org/sssd/ticket/1783
  Group lookup fails and takes ~60s to return to shell if member dn is
  incorrect
* https://fedorahosted.org/sssd/ticket/1782
  TOCTOU race conditions by copying and removing directory trees

== Detailed Changelog ==
Jakub Hrozek (9):
 * Updating the version for the 1.8.6 release
 * Initialize Kerberos ticket renewal in the IPA provider
 * LDAP: Check validity of naming_context
 * Free the internal DP request
 * Do not always return PAM_SYSTEM_ERR when offline krb5 authentication fails
 * NSS: Fix netgroup midpoint cache refresh
 * TOOLS: Use openat/unlinkat when removing the homedir
 * TOOLS: Compile on old platforms such as RHEL5
 * Include the auth_utils.h header in the distribution

Jan Cholasta (1):
 * Check that strings do not go beyond the end of the packet body in
   autofs and SSH requests.

Ondrej Kos (2):
 * Restart services with a delay in case they are restarted too often
 * TOOLS: Use file descriptor to avoid races when creating a home directory

Pavel Březina (1):
 * nested groups: fix group lookup hangs if member dn is incorrect

Simo Sorce (2):
 * responder_dp: Add timeout to side requets
 * sssd_pam: Cleanup requests cache on sbus reconect

Stephen Gallagher (1):
 * LDAP: Handle empty namingContexts values safely

Timo Aaltonen (1):
 * link sss_ssh_authorizedkeys and sss_ssh_knownhostsproxy with -lpthread
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] migrating from NIS to AD+kerberos

[Jakub Hrozek]

On Wed, Feb 13, 2013 at 11:28:17AM +, Longina Przybyszewska wrote:
>   
> 
> As a continuation of sssd evaluatin we  plan migration  from NIS  to Active 
> Directory+Kerberos.
> 
> Now again the question - what is the best approach and practice to migrate 
> users ?
> 
> AD administrators enabled SFU, and we got extended schema with POSIX 
> attributes.
> I guess there might be some free or commercial tools for extracting data from 
> NIS and loading into AD -ldap objects.
> 
> Our Linux users are dispersed in separated NIS domains, and all have  AD 
> account beside the entry in NIS.
>  Home directories are  NFS-mounted   with autofs  from Linux storage server 
> but some users access  MSWin storage with smbclient.
> 
> Can you share experiences on assigning POSTFIX attributes in SSSD context,  
> best practice etc..? 

I assume you meant POSIX
attributes.

> We would not like activate NIS services on AD server for migration.
> 
> Longina

Hi,

I don't know any tools to migrate users from NIS to AD myself, maybe
others on this list do.

In general starting with SSSD 1.9 you don't need to enable SFU and
populate the POSIX attributes at all, you can just use the SSSD
ID-mapping feature to map AD SIDs to UNIX IDs automatically. I'm not
sure if that's a good idea in your particular case, because most
probably the mapped attributes would be different than those you have
manually created in NIS. Just saying.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] Announcing SSSD 1.5.17

[Jakub Hrozek]

=== SSSD 1.5.17 ===

The SSSD team is proud to announce the bugfix release of the System
Security Services Daemon version 1.5.17

As always, the source is available from https://fedorahosted.org/sssd

According to our current plan, this would be the last release done on
the 1.5 LTM branch upstream. When the next 1.9 release is out, it will
be proclamed LTM and the 1.5 branch would go completely EOL upstream,
with the exception of serious security issues or serious regressions
caused by this release.

== Feedback ==

Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

== Highlights ==

* A security bug assigned CVE-2013-0219 was fixed - TOCTOU race
  conditions when creating or removing home directories for users in
  local domain
* Monitoring and restarting child processes was made more robust
* The ipa_hbac_support_srchost option was backported, defaulting
  to false.
* The limit of file descriptors a responder is allowed to open is
  configurable using the fd_limit option
* Idle client connections are terminated in the responder 

== Tickets fixed ==

* https://fedorahosted.org/sssd/ticket/1139
* https://fedorahosted.org/sssd/ticket/1214
* https://fedorahosted.org/sssd/ticket/1324
* https://fedorahosted.org/sssd/ticket/1226
* https://fedorahosted.org/sssd/ticket/1227
* https://fedorahosted.org/sssd/ticket/1130
* https://fedorahosted.org/sssd/ticket/1197
* https://fedorahosted.org/sssd/ticket/1078
* https://fedorahosted.org/sssd/ticket/1782 

== Detailed Changelog ==

Jakub Hrozek (8):
* Rename fo_get_server_name to fo_get_server_str_name
* fo_get_server_name() getter for a server name
* Only do one cycle when resolving a server
* Detect cycle in the fail over on subsequent resolve requests only
* Try all KDCs when getting TGT for LDAP
* HBAC: create empty groups with one NULL element
* Process all groups from a single nesting level
* TOOLS: Use openat/unlinkat when removing the homedir 

Jan Zeleny (1):
* Add ipa_hbac_support_srchost option to IPA provider 

Ondrej Kos (7):
* Add common SIGCHLD handling for providers
* Cancel ping-check if service goes away
* MONITOR: use sigchld handler for monitoring SSSD services
* Add new debug level macros
* UTIL: Add function for atomic I/O
* TOOLS: Use file descriptor to avoid races when creating a home directory
* TOOLS: Compile on old platforms such as RHEL5 

Shantanu Goel (4):
* Set return errno to the value prior to calling close().
* Log message if close() fails in destructor.
* Do not send SIGPIPE on disconnection
* Add support for terminating idle connections 

Stephen Gallagher (14):
* Bumping version to 1.5.17
* Fix potential resource leak in backup_file.c
* Log fixes for sdap_call_conn_cb
* LDAP: Copy URI instead of pointing at failover service record
* IPA: Detect nsupdate support for the realm directive
* DP: Reorganize memory hierarchy of requests
* Make the client idle timeout configurable
* LDAP: Make sdap_access_send/recv public
* IPA: Check nsAccountLock during PAM_ACCT_MGMT
* Also expire connections on the privileged pipe
* RESPONDERS: Allow increasing the file-descriptor limit
* RESPONDERS: Make the fd_limit setting configurable
* Converge accept_fd_handler and accept_priv_fd_handler
* SYSDB: Make sysdb_attrs_get_el_int() public 
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] migrating from NIS to AD+kerberos

[Jakub Hrozek]

On Thu, Feb 14, 2013 at 11:24:23AM +, Longina Przybyszewska wrote:
> UID/GID allocating – is my missing link.
> We need to renumber at least UIDs as they overlap across NIS domains.
> As all users have in advance AD account it seems obvious to me to generate 
> posix uid based on AD IDs.
> 

If you're renumbering the UIDs (and by extension changing the file
permissions) anyway, you might as well go with the ID mapping feature
completely.

> …Or just assign Linux UIDs numbers  during migrating.
> What about making new accounts in the future – how the uid would be generated 
> for Linux Users?
> Do we need a special group say ‘linuxusers’  then make a new template for new 
> account in the group?
> Can AD make for us also continuously unique POSIX  UIDs when creating the new 
> account?
> I don’t know YET much about MSWin identification process – sorry for very 
> basic questions ;).
> 
> I understand that the approach with RID (real ID ??) mapping achieves 
> consistent name mapping across all types file servers –
> am I right?

I'm not sure what you mean by "across all types of file servers" but
the mapping should be consistent, yes.

> But maybe in sssd context it doesn’t make sense – as Ondrej points out.
> 
> Ondrej, if you say “sssd can serve automount maps for automounter” – that 
> means sssd can read ldap automounter map, and do
> it automatically if we define  autofs service in [nss] but first automounter 
> has to know about sssd and link to sssd libraries?
> 

See http://jhrozek.livejournal.com/2500.html for example.


> Alternative,  now we have to convert NIS auto.home maps to ldap format, and 
> load them to AD (???), then reconfigure automounter to
> ask AD for entry instead of NIS.
> By the way how do I find what class/attributes I want in AD-ldap for autofs?
> 
> Longina
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Fedora 18, FreeIPA and password expiration warning

[Jakub Hrozek]

On Mon, Feb 18, 2013 at 12:12:32AM -0600, Anthony Messina wrote:
> I have just upgraded a few of my machines from Fedora 17 to Fedora 18 
> (sssd-1.9.4-3.fc18.x86_64) and on the F18 machines, users are now presented 
> with the "Your password will expire in 204 days..." message.  All machines 
> are 
> connected to an F17 FreeIPA server (freeipa-server-2.2.1-2.fc17.x86_64) which 
> has the "Password Expiration Notification (days)" set to 30.
> 
> I've been reading up on the "pam_pwd_expiration_warning (integer)" variable 
> in 
> the sssd.conf man page, and the default is supposed to be "0", which I think 
> should allow the FreeIPA configuration to pass through.
> 
> Is there something I'm missing here?  I'm pretty sure people don't need to 
> see 
> the prompt at every login for the next 204 days, even though i bet some of 
> them will still not have changed their password ;)
> 
> Thanks in advance.  -A

Hi Anthony,

you are hitting bug https://fedorahosted.org/sssd/ticket/1808 A patch is
already on the list. Once it's peer-reviwed, I'll submit an update for
Fedora.

I also cloned the updstream ticket to
https://bugzilla.redhat.com/show_bug.cgi?id=912223 so that we can track
the problem in Fedora. Sorry for the inconvenience.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Empty groups with sssd 1.9.4

[Jakub Hrozek]

On Wed, Feb 20, 2013 at 08:23:04AM +0100, Michael Ströder wrote:
> Pavel Březina wrote:
> >> But I'm struggling that groups are not correctly retrieved - see my last
> >> attempt of sssd.conf attached.
> >>
> >> 1. After login id does not show the user's groups although the OpenLDAP 
> >> logs
> >> show that group entries are searched and returned to sssd by OpenLDAP's 
> >> slapd.
> > 
> > can you raise debug level in nss, sudo and domain section to 9 (put
> > debug_level = 9 in [nss], [sudo] and [domain/yourdomain] sections in
> > sssd.conf? What does the logs say?
> 
> It turned out to be a bug in our own Debian package.
> The lib memberof.so was not found.
> 
> Now I'm still working on getting sudoers to work via sssd. But that's another
> story...

Glad the issue was resolved! Feel free to ping this list again if you
can't get the sudo integration working. Please note you need relatively
recent sudo built with the --with-sssd (not sure if Debian would do that
even in -unstable/-testing)
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] attribute decoding error is breaking LDAP integration

[Jakub Hrozek]

On Wed, Feb 20, 2013 at 08:56:10AM -0800, Scott Classen wrote:
> 
> Well I got SSSD and LDAP working so I thought I'd post something here for 
> posterity's sake.
> 
> 
> On Feb 19, 2013, at 5:22 PM, Dmitri Pal wrote:
> 
> > On 02/19/2013 05:01 PM, Scott Classen wrote:
> >> Hello,
> >> 
> >> sssd appears to bind successfully, but when it tries to fetch user 
> >> information id balks. Here is a snippit from the log file immediately 
> >> after the successful bind.
> >> 
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [simple_bind_done] (0x0080): 
> >> Bind result: Success(0), no errmsg set
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [fo_set_port_status] 
> >> (0x0100): Marking port 389 of server 'mymachine' as 'working'
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [set_server_common_status] 
> >> (0x0100): Marking server 'mymachine' as 'working'
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_get_generic_ext_done] 
> >> (0x0040): Unexpected result from ldap: Protocol error(2), Dereference 
> >> control: attribute decoding error
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_x_deref_search_done] 
> >> (0x0100): sdap_get_generic_ext_recv failed [5]: Input/output error
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_deref_search_done] 
> >> (0x0040): dereference processing failed [5]: Input/output error
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_nested_done] (0x0020): 
> >> Nested group processing failed: [5][Input/output error]
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [acctinfo_callback] 
> >> (0x0100): Request processed. Returned 3,5,Group lookup failed
> >> (Tue Feb 19 13:49:14 2013) [sssd[nss]] [nss_cmd_getgrgid_dp_callback] 
> >> (0x0040): Unable to get information from Data Provider
> >> Error: 3, 5, Group lookup failed
> >> Will try to return what we have in cache
> >> 
> >> 
> >> ldpasearch works fine:
> >> 
> >> ldapsearch -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret 
> >> "cn=somegroupname" -LL
> >> 
> >> and produces copious information about all the members of "somegroupname"
> >> 
> >> 
> >> this is causing a major headache as a simple ls -l will hang the system.
> >> 
> > 
> > What is the version of SSSD and what kind of directory it uses?
> 
> 
> SSSD version 1.8.0 as distributed through CentOS 6.
> OpenLDAP version 2.4.32 built from source
> 
> 
> > It seems, based on the error message, that LDAP server supplies a deref 
> > control that SSSD fails to parse. Is there something special in your LDAP 
> > server or something changed recently?
> 
> Nothing has changed with the OpenLDAP server. We do have some special 
> schemas, but I don't think that is the problem
> 
> > LDAP search might work OK because it does not try to process the control.
> > 
> > Is this an issue that suddenly started to happen or it just does not work 
> > out of box?
> > In either cases the reason for this is most likely on the server side.
> > Is there any way to get more info from the server side about what kind of 
> > control was actually sent?
> 
> 
> So the solution was to add the following line to my sssd.conf file
> 
> enumerate = true
> 
> That's it.
> 
> Everything works now.
> 
> id username returns useful information.
> getent works.
> ls -l works.
> 
> Not exactly sure why enumerate = true would fix my problem? I would expect 
> that the underlying mechanism used to gather user/group information from 
> OpenLDAP would be the same regardless of whether enumeration is turned on or 
> off. My understanding from reading the sssd documentation is that enumeration 
> merely caches the user/group information locally. There must be something 
> else going on that is causes the system to hang when enumeration is set to 
> false/
> 
> Anyways that's as far as I got. I'm happy that things are working now.
> 
> Scott
> 

Hi,

The dereference processing can only work if the attributes
being dereferenced (usually member:) are DNs (DN_SYNTAX_OID). Does your
schema maybe touch the member attributes in any way? Do all your groups
really use the member attribute and not for instance uniqueMember?

Turning the enumeration on merely works around the problem by following
a different code path.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Empty groups with sssd 1.9.4

[Jakub Hrozek]

On Wed, Feb 20, 2013 at 09:39:26PM +0100, Michael Ströder wrote:
> Jakub Hrozek wrote:
> > Feel free to ping this list again if you
> > can't get the sudo integration working. Please note you need relatively
> > recent sudo built with the --with-sssd (not sure if Debian would do that
> > even in -unstable/-testing)
> 
> Aah, this is a good hint where to look. And yes, I couldn't get it to work
> under Debian Squeeze.
> 
> Could you please provide the minimum sudo version required?
> 
> Ciao, Michael.

I believe that any 1.8.x version would do, but as I said, the sudo must
be configured with --with-sssd. 

Also, I'm not sure from the top of my head how the debian packaging looks
like, but you'd also need to have the sssd's sudo plugin installed. On
Fedora the plugin belongs to libsss_sudo package and is stored at
/usr/lib{,64}/libsss_sudo.so
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] attribute decoding error is breaking LDAP integration

[Jakub Hrozek]

On Wed, Feb 20, 2013 at 01:20:23PM -0800, Scott Classen wrote:
> On Feb 20, 2013, at 12:41 PM, Jakub Hrozek wrote:
> 
> >> So the solution was to add the following line to my sssd.conf file
> >> 
> >> enumerate = true
> >> 
> >> That's it.
> >> 
> >> Everything works now.
> >> 
> >> id username returns useful information.
> >> getent works.
> >> ls -l works.
> >> 
> >> Not exactly sure why enumerate = true would fix my problem? I would expect 
> >> that the underlying mechanism used to gather user/group information from 
> >> OpenLDAP would be the same regardless of whether enumeration is turned on 
> >> or off. My understanding from reading the sssd documentation is that 
> >> enumeration merely caches the user/group information locally. There must 
> >> be something else going on that is causes the system to hang when 
> >> enumeration is set to false/
> >> 
> >> Anyways that's as far as I got. I'm happy that things are working now.
> >> 
> >> Scott
> >> 
> > 
> > Hi,
> > 
> > The dereference processing can only work if the attributes
> > being dereferenced (usually member:) are DNs (DN_SYNTAX_OID). Does your
> > schema maybe touch the member attributes in any way? Do all your groups
> > really use the member attribute and not for instance uniqueMember?
> > 
> > Turning the enumeration on merely works around the problem by following
> > a different code path.
> 
> Jakub,
> 
> my custom schema only extends the posixAccount to add some extra attributes. 
> I make no changes to posixGroup.
> 
> ldapsearch -ZZ -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret 
> "uniqueMember=*"
> 
> returns nothing.
> 
> ldapsearch -ZZ -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret 
> "member=*"
> 
> returns the 175 groups in my ldap directory.
> 
> An example for a specific group (e.g. dvd) would be:
> 
> ldapsearch -ZZ -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret "cn=dvd"
> 
> # extended LDIF
> #
> # LDAPv3
> # base  with scope subtree
> # filter: cn=dvd
> # requesting: ALL
> #
> 
> # dvd, Group, mydomain
> dn: cn=dvd,ou=Group,dc=mydomain
> objectClass: posixGroup
> objectClass: groupOfNames
> objectClass: top
> objectClass: apple-group
> objectClass: extensibleObject
> cn: dvd
> gidNumber: 9075
> description: dvd burner admin group
> member: uid=user1,ou=People,dc=mydomain
> member: uid=user2,ou=People,dc=mydomain
> 
> # search result
> search: 3
> result: 0 Success
> 
> # numResponses: 2
> # numEntries: 1
> 
> 
> I hope this helps.
> 
> Scott

Does the following:

ldapsearch -x -H ldap://ldap.example.com -E 'deref=member:cn,objectclass' -b 
cn=ou=Group,dc=mydomain 'cn=dvd'

Work for you? The command should yield user1 and user2's cn and
objectclass.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] override_homedir , GUIDs problem

[Jakub Hrozek]

On Wed, Feb 27, 2013 at 10:11:03AM +, Longina Przybyszewska wrote:
> Hi,
> This is SSSD-VERSION 1.9.4 , Ubuntu Quantal 12.10
> If homedir doesn't exist, user cannot login - homedir is not created locally  
> on fly. Is it expected behavior?
> 
> 
> [nss]
> ...
> fallback_homedir = /home/%u 
> override_homedir = /home/%u
> ...
> 
> Do I suppose to  make change in pam to get it work?
> 

Yes, you should put pam_mkhomedir or pam_oddjob into the session stack.

> --
> Another problem - with group IDs:
> 
> After login to the terminal, I get the long list  of warnings for all groups 
> 1172x - it really delays login,
> as the list is long. Do I miss some config options ?
> 
> su - testuser 
> ...
> groups: cannot find name for group ID XXX
> ...
> 

That's quite suspicious. How deep is your nesting structure? Are the
groups that you only see numbers for two or more levels deep? The only
known bug that could be related is
https://fedorahosted.org/sssd/ticket/1755

can you try setting ldap_group_nesting_level to a higher number to check
if the issue is resolved?

> id -G testuser
> 332400513 332411734 332411220 332411221 332405659 332410635 332403786 
> 332403699 332407177 332408204 332408312 332406100 332408307 332413664 
> 332402685 332402830 332411184
> 
> id -G -n  testuser
> domain users data-nat-nat-it-groupdrive rw nat-fnc-pri-setdiscription 
> nat-pri-setcomputerdesc imada-terminal-users nat-it-outlook-admin 
> nat-terminal-users terminal brugere dl-nat-it-staff nat-it-ansatte 
> nat-it-ad-hoc nat-esignatur dl-nat-it nat-ctxusers common_users nat-lectures 
> nat-booking
> 
> id testuser
> uid=332405654(testuser) gid=332400513(domain users) groups=332400513(domain 
> users),1172612322,1172651920,1172657894,1172606592,1172607216,
> 332411734(data-nat-nat-it-groupdrive 
> rw),332411220(nat-fnc-pri-setdiscription),332411221(nat-pri-setcomputerdesc),332405659(i-terminal-users),
> 332410635(nat-it-outlook-a),332403786(nat-terminal-users),332403699(terminal 
> brugere),332407177(dl-nat-it-staff),332408204(nat-it-ansatte),
> 332408312(nat-it-ad-hoc),332406100(nat-esignatur),1172648735,332413664(nat-ctxusers),332402685(common_users),332402830(nat-lectures),332411184(nat-booking),
> 332408307(dl-nat-it),1172668083,1172671850,1172626924,1172670697,1172632585,1172647528,1172673996,
> 1172630281,1172650784,1172649006,1172646018,1172626637,1172668082,1172647518,1172647527,1172647519,
> 1172671034,1172652129,1172650787,1172608193,1172646019,1172649007,1172645844,1172630472,1172648739,1172645167,
> 1172649004,1172649400,1172671853,1172650786,1172645166,1172645845,988802256,1172649005,1172659655,1172647852,1172633504,
> 1172667765,1172666809,1172645842,1172649046,1172667764,1172647523,1172626846,1172633505,1172645161,1172658369,1172645843,
> 1172616454,1172659249,1172645163,1172644173,1172670698,988803287,1172645162,1172645841,1172659248,1172666810,1172659262,1172626838,
> (a lot of groups)...
> 1172648736,1172679679,1172622933,1172679716,1172645975,1172671030,1172620701,1172681776,1172650191
> 
> 
> Best
> Longina
> 
> ___
> 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

Re: [SSSD-users] override_homedir , GUIDs problem

[Jakub Hrozek]

On Wed, Feb 27, 2013 at 01:36:58PM +, Longina Przybyszewska wrote:
> 
> On Wed, Feb 27, 2013 at 10:11:03AM +, Longina Przybyszewska wrote:
> 
> > --
> > Another problem - with group IDs:
> > 
> > After login to the terminal, I get the long list  of warnings for all 
> > groups 1172x - it really delays login, as the list is long. Do I miss 
> > some config options ?
> > 
> > su - testuser
> > ...
> > groups: cannot find name for group ID XXX ...
> > 
> 
> >>That's quite suspicious. How deep is your nesting structure? Are the groups 
> >>that you only see numbers for two or more levels deep? The only known bug 
> >>that could be related is
> >>https://fedorahosted.org/sssd/ticket/1755
> 
> >>can you try setting ldap_group_nesting_level to a higher number to check if 
> >>the issue is resolved?
> 
> How can I find out about the nesting structure in AD?
> 
> I tried with nesting_level 3|4|5
> 
> It doesn't help for login issue - the same long list for all nesting levels 
> of from command
> 
>  su - testuser
> 
> 
> The   number of groups listed in  'id ' command changes with 'nesting_level': 
> 
> (Nesting level =5)
> alongina@victoria:~$ id -G testuser
> 332400513
> alongina@victoria:~$ id -G -n testuser
> domain users
> alongina@victoria:~$ id testuser
> uid=332405654(testuser) gid=332400513(domain users) groups=332400513(domain 
> users)
> 
> (nesting level=4)
> 
> alongina@victoria:~$ id -G testuser
> 332400513 332411734 332411220 332411221 332405659 332410635 332403786 
> 332403699 332407177 332408204 332408312 332406100 332408307 332413664 
> 332402685 332402830 332411184
> alongina@victoria:~$ id -G -n testuser
> domain users data-nat-nat-it-groupdrive rw nat-fnc-pri-setdiscription 
> nat-pri-setcomputerdesc imada-terminal-users nat-it-outlook-admin 
> nat-terminal-users terminal brugere dl-nat-it-staff nat-it-ansatte 
> nat-it-ad-hoc nat-esignatur dl-nat-it nat-ctxusers common_users nat-lectures 
> nat-booking
> alongina@victoria:~$ id testuser
> uid=332405654(longina) gid=332400513(domain users) groups=332400513(domain 
> users),332411734(data-nat-nat-it-groupdrive 
> rw),332411220(nat-fnc-pri-setdiscription),332411221(nat-pri-setcomputerdesc),332405659(imada-terminal-users),332410635(nat-it-outlook-admin),332403786(nat-terminal-users),332403699(terminal
>  
> brugere),332407177(dl-nat-it-staff),332408204(nat-it-ansatte),332408312(nat-it-ad-hoc),332406100(nat-esignatur),332408307(dl-nat-it),332413664(nat-ctxusers),332402685(common_users),332402830(nat-lectures),332411184(nat-booking)
> 
> 
> It  depends somehow on cache.
> Just after emptying cache I  get the very long listing.
> 
> root@victoria:/var/lib/sss/db# service sssd stop
> sssd stop/waiting
> root@victoria:/var/lib/sss/db# \rm -rf *
> root@victoria:/var/lib/sss/db# service sssd start
> sssd start/running, process 3635
> root@victoria:/var/lib/sss/db# id testuser
> uid=332405654(testuser) gid=332400513(domain users) groups=332400513(doma
> in users),332402685(common_users),1172668083,1172671850,1172626924,11726
> 70697,1172632585,1172657894,1172647528,1172673996,1172630281,1172650784,
> 1172649006,1172646018,1172626637,1172668082,1172647518,332406100(nat-esi
> gnatur),332403786(nat-terminal-users),1172647527,332405659(imada-termina
> l-users),1172647519,1172671034,1172652129,1172650787,1172608193,11726460
> 19,1172649007,1172645844,1172630472,1172648739,1172645167,332402830(nat-
> lectures),1172649004,1172649400,1172671853,1172650786,332408307(dl-nat-i
> t),1172645166,1172645845,988802256,1172651920,1172649005,1172659655,1172
> 606592,1172647852,1172633504,1172667765,1172666809,1172645842,1172649046
> ,1172667764,1172647523,1172626846,1172633505,1172645161,1172658369,11726
> 45843,1172616454,1172607216,332411221(nat-pri-setcomputerdesc),117265924
> 9,332410635(nat-it-outlook-admin),1172645163,1172644173,1172670698,98880
> 3287,1172645162,1172645841,1172659248,1172666810,1172659262,1172626838,1
> 172647520,988807606,1172626843,332411220(nat-fnc-pri-setdiscription),117
> 2612780,1172649045,1172645152,1172645147,1172626938,1172658370,117265836
> 5,1172630586,1172649398,1172627322,332413664(nat
> -ctxusers),1172607213,1172626943,1172649060,1172681172,332408204(nat-it-ansatte),1172632583,1172658364,1172626827,332407177(dl-nat-it-staff),1172658371,1172653861,1172645344,332403699(terminal
>  
> brugere),1172649061,1172645146,1172632578,1172671847,1172626940,1172626841,1172648741,1172649062,1172632579,1172658363,1172627278,1172645150,1172653860,332411184(nat-booking),332408312(nat-it-ad-hoc),1172632582,1172645145,1172671028,1172645144,1172627767,1172626935,1172632581,1172672165,1172645151,1172671032,332411734(data-nat-nat-it-groupdrive
>  
> rw),1172657810,1172612322,1172650789,1172648253,1172657811,1172681132,1172648254,1172649064,1172627766,1172645974,1172672164,1172671286,1172632580,1172648736,1172679679,1172622933,1172679716,1172645975,1172671030,1172620701,1172681776,1172650191,1172648735
> 
> The same command is

Re: [SSSD-users] override upn

[Jakub Hrozek]

On Mon, Mar 18, 2013 at 01:00:07PM +, Longina Przybyszewska wrote:
> Thanks, your advice was helpful.
> 
> By the way, does 'default_realm' reference in /etc/krb5.conf   is for finding 
> realm
> for  users AND hosts? 
> 
>  [libdefaults]
> 
> ..
> default_realm = C.MY.DOMAIN
> 
> 
> If authentication is against  AD+Krb,  is there difference between 'ad' and 
> 'krb5' providers in options:
> access_provider = 

Yes, this is different, access_provider=ad checks in LDAP if the account
is disabled or not. If you were using access_provider=krb5 previously,
you should keep using that option, it should just work.

I checked the sssd-ad man page and realized this is not documented
properly. So I filed:
https://fedorahosted.org/sssd/ticket/1841

> auth_provider = 
> chpass_provider =

There is no difference in behaviour of these providers between krb5 and ad.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sss_ssh_authorizedkeys returns "Error looking up public keys"

[Jakub Hrozek]

On Tue, Mar 19, 2013 at 01:56:20PM -0400, Mathieu Lemoine wrote:
> Hello,
> 
> I have sssd 1.9.4 (from
> https://launchpad.net/~nicholas-hatch/+archive/auth/+packages) configured
> on an OpenLDAP server.
> getent passwd, getent group, authentication and cache is working great.
> 
> My issue now lies with the SSH public key.
> 
> My user has the ldapPublicKey objectClass, and the key is in the
> sshPublicKey attribute.
> 
> sss_ssh_authorizedkeys is still returning "Error looking up public keys".
> An inquiry on the #sssd chan directed me to this mailing-list and more
> precisely to jcholast, I tried to check out the commits, but nothing seems
> to get out of it...

Full disclosure: I was the one who redirected Mathieu to you, Honza :-)

> 
> If any of you had informations regarding that, it'd be greatly appreciated.,
> Mathieu.

I think as a first step, it would be nice to put debug_level=8 into the
[ssh] section of the sssd.conf file, restart the SSSD and then attach
the ssh responder logs (/var/log/sssd/sssd_nss.log).

Also the sssd.conf (sanitized if needed) would come handy.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sss_ssh_authorizedkeys returns "Error looking up public keys"

[Jakub Hrozek]

On Tue, Mar 19, 2013 at 07:15:21PM +0100, Jakub Hrozek wrote:
> On Tue, Mar 19, 2013 at 01:56:20PM -0400, Mathieu Lemoine wrote:
> > Hello,
> > 
> > I have sssd 1.9.4 (from
> > https://launchpad.net/~nicholas-hatch/+archive/auth/+packages) configured
> > on an OpenLDAP server.
> > getent passwd, getent group, authentication and cache is working great.
> > 
> > My issue now lies with the SSH public key.
> > 
> > My user has the ldapPublicKey objectClass, and the key is in the
> > sshPublicKey attribute.
> > 
> > sss_ssh_authorizedkeys is still returning "Error looking up public keys".
> > An inquiry on the #sssd chan directed me to this mailing-list and more
> > precisely to jcholast, I tried to check out the commits, but nothing seems
> > to get out of it...
> 
> Full disclosure: I was the one who redirected Mathieu to you, Honza :-)
> 
> > 
> > If any of you had informations regarding that, it'd be greatly appreciated.,
> > Mathieu.
> 
> I think as a first step, it would be nice to put debug_level=8 into the
> [ssh] section of the sssd.conf file, restart the SSSD and then attach
> the ssh responder logs (/var/log/sssd/sssd_nss.log).

 
Sorry, this is a copy-n-paste error. The *ssh* responder log is located
at:
/var/log/sssd/sssd_ssh.log

The path I copied was the *nss* responder log. Sorry again.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] A security bug in SSSD 1.9 (CVE-2013-0287)

[Jakub Hrozek]

=== A security bug in SSSD 1.9 ===
=
= Subject: A simple access provider flaw prevents intended ACL use
=  when SSSD is configured as an Active Directory client
=
= CVE ID#: CVE-2013-0287
=
= Summary: When SSSD is configured as an Active Directory client by
=  using the new Active Directory provider or equivalent
=  configuration of the LDAP provider, the Simple Access
=  Provider does not handle access control correctly.
=  If any groups are specified with the simple_deny_groups
=  option, the group members are permitted access.
=
= Impact:  medium
=
= Acknowledgements: The bug was found by Kaushik Banerjee of Red Hat
=   Quality Engineering team
=
= Affects default
=  configuration:   no
=
= Introduced with:  1.9.0
=
===
 
 DESCRIPTION 
 
SSSD versions 1.9.0 and later are vulnerable to a security bug.
 
If the SSSD is configured to use the Active Directory provider (or equivalent
configuration of the LDAP provider) along with the Simple Access Provider
which in turn uses the simple_deny_groups option, then even groups listed
in that configuration option would be allowed access.

The reason is that the AD provider obtains a list of groups the user is a
member of in form of SIDs which are algorithmically transformed into GIDs
during the initgroups operation. Thus, contrary to the LDAP provider,
the group names might not be known during the account phase of the PAM
conversation. As a result, groups listed in the simple_deny_groups option may
be allowed access and groups in the simple_allow_groups may be denied access.

The vulnerable LDAP provider configuration would include the "ldap_schema=ad"
option, use the SID-to-ID mapping (ldap_id_mapping=True), would be connected
to an Active Directory server and use the simple_deny_groups as mentioned
above.
 
The fix will be delivered as part of the upcoming 1.9.5 release.
 
The bug is being tracked in the following Red Hat Bugzilla report:
https://bugzilla.redhat.com/show_bug.cgi?id=910938
 
 PATCH AVAILABILITY 
 
The patches for the master branch are available at:
http://git.fedorahosted.org/cgit/sssd.git/patch/?id=c0bca1722d6f9dfb654ad78397be70f79ff39af1
http://git.fedorahosted.org/cgit/sssd.git/patch/?id=6569d57e3bc168e6e83d70333b48c5cb43aa04c4
http://git.fedorahosted.org/cgit/sssd.git/patch/?id=6837eee3f7f81c0ee454d3718d67d7f3cc6b48ef
http://git.fedorahosted.org/cgit/sssd.git/patch/?id=7619be9f6bf649665fcbeee9e6b120f9f9cba2a5

The patches for the sssd-1-9 branch are available at:
http://git.fedorahosted.org/cgit/sssd.git/patch/?id=8b8019fe3dd1564fba657e219ec20ff816c7ffdb
http://git.fedorahosted.org/cgit/sssd.git/patch/?id=26590d31f492dbbd36be6d0bde46a4bd3b221edb
http://git.fedorahosted.org/cgit/sssd.git/patch/?id=754b09b5444e6da88ed58d6deaed8b815e268b6b
http://git.fedorahosted.org/cgit/sssd.git/patch/?id=b63830b142053f99bfe954d4be5a2b0f68ce3a93

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

Re: [SSSD-users] sss_ssh_authorizedkeys returns "Error looking up public keys"

[Jakub Hrozek]

On Wed, Mar 20, 2013 at 08:12:33AM -0400, Simo Sorce wrote:
> On Wed, 2013-03-20 at 10:19 +0100, Pavel Březina wrote:
> > 
> > Hi,
> > I'm afraid we support ssh keys only with IPA backend at the moment.
> > 
> 
> Should we open a RFE to make it available with other backends too ?
> 

This is already part of https://fedorahosted.org/sssd/ticket/1560 it
seems:

"""
In the LDAP provider, ldap_user_ssh_public_key has no default value.
Make sshPublicKey the default value for it, so that OpenSSH-LPK support
is enabled by default. 
"""
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] sss_ssh_authorizedkeys returns "Error looking up public keys"

[Jakub Hrozek]

On Wed, Mar 20, 2013 at 12:26:51PM -0400, Mathieu Lemoine wrote:
> My Bad... And there we go, everything seems to be working just fine.
> Thank you very much for your help!
> 
> I'll give it a rest for a couple of days to make sure the cache is working
> fine for my use case and then I'll document my experience in a blog post.
> I hope this will be able to help others and prevent further stupid mistakes
> like mine!
> 
> Thanks again,
> Mathieu.
> 

That would be great, thank you. Please let us know when/if you publish
that blog post. I think it would be nice to link it from the sssd wiki
or turn it into a howto document there.

> 2013/3/20 Jan Cholasta 
> 
> > On 20.3.2013 15:41, Mathieu Lemoine wrote:
> >
> >> Hello,
> >>
> >> Thanks for all the messages.
> >> I did add the ldap_user_public_key to sssd.conf, but it doesn't seem to
> >> change anything.
> >>
> >> In fact, sshPublicKey isn't even requested during the
> >> ldap_search_ext/sdap_get_**generic_ext_step call.
> >>
> >> I tried to find information on IPA backend, but it seems quite unclear
> >> what this would be.
> >> Attached is an up-to-date sanitized sssd.conf.
> >>
> >> If you have any other insight, I'd be glad to test them or provide
> >> additional informations.
> >>
> >> Mathieu.
> >>
> >>
> > The option is named "ldap_user_ssh_public_key", not "ldap_user_public_key".
> >
> > Honza
> >
> > --
> > Jan Cholasta
> >

> ___
> 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