[Freeipa-users] Unofficial SSSD 1.9.x repository for RHEL 5

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Due to popular request, I am offering a completely unofficial and
unsupported repository of the latest 1.9.x LTM bits for RHEL 5 and
derivatives. The latest official version supported by the distribution
is 1.5.x.

These packages are built from the upstream sources using the same spec
file that was used to generate the nightly builds back when 1.9.x was
the master branch, so it's expected to work just fine.

You can find the repository and instructions how to use it at:
http://copr-fe.cloud.fedoraproject.org/coprs/sgallagh/sssd-1.9-rhel5/


Please do not file bugs against Bugzilla for issues discovered with
these builds.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMGAwAACgkQeiVVYja6o6McygCdH6OGn//W3Po7XokoHLEOIzS+
0VUAoK8mfaLdSzzoLpFZMLd/gFqNf5YY
=xEFs
-END PGP SIGNATURE-

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/21/2013 09:04 AM, Jan-Frode Myklebust wrote:
> Serverdefault has a hack for supporting nested groups on 
> RHEL5/apache-2.2 involving a ldap filter using 
> LDAP_MATCHING_RULE_IN_CHAIN on Active Directory, ref:
> 
> http://serverfault.com/a/424706
> 
> Does anybody know if a similar filter can be created for an with 
> IPA/389ds backend ?
> 

Just as an FYI (slightly off-topic), we discovered in SSSD that the
problem with this approach on Active Directory is that the matching
rule searches are not indexed, so on large AD deployments it can take
seconds (sometimes tens of seconds) to return the results.

FreeIPA's solution is much simpler and more elegant. When group
memberships are stored in the server, we create backlinks at
save-time. All users contain an attribute 'memberOf' that
automatically handles nestings. So if GroupB is a member of GroupA and
UserC is a member of GroupB, then UserC will have:
memberOf: cn=GroupB,...
memberOf: cn=GroupA,...

So you can always get the complete list of groups a user belongs to with:
ldapsearch  -H ldap://ipaserver.example.com \
   -b  -s base "(objectClass=*)" memberOf


Or the complete set of users in a group with:
ldapsearch  -H ldap://ipaserver.example.com \
   -b  \
"(&(objectClass=posixUser)(memberOf=cn=groupname,...))"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFMTB4ACgkQeiVVYja6o6PFcgCgmVVlXHup70Ecnm8OcY4VIhYr
yJUAnRlyDeJ3HA+WveLT0WrQw/I0IqZZ
=H/Yx
-END PGP SIGNATURE-

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Joining Fedora 18 (FreeIPA 3.1.0) to CentOS 6.3 (FreeIPA 2.1.90rc1)

[Stephen Gallagher]

On 12/28/2012 10:23 AM, Michael B. Trausch wrote:

On 12/28/2012 08:56 AM, Simo Sorce wrote:

However re-reading the ticket made me wonder. Is this happening on the
F18 machine or on the Centos 6.3 machine ?


The sigsegv is happening on the Fedora 18 box, the one running FreeIPA
3.1.0.

I am completely unable to install debug symbols for the following libraries:

===
Missing separate debuginfos, use: debuginfo-install
cyrus-sasl-gssapi-2.1.25-2.fc18.x86_64
cyrus-sasl-lib-2.1.25-2.fc18.x86_64 cyrus-sasl-md5-2.1.25-2.fc18.x86_64
cyrus-sasl-plain-2.1.25-2.fc18.x86_64 glibc-2.16-28.fc18.x86_64
pcre-8.31-3.fc18.x86_64 sssd-client-1.9.3-1.fc18.x86_64
===

When I run that command, I get the following message:

===
No debuginfo packages available to install
===

Which of course, is unhelpful.

--- Mike




That's the problem with running Fedora pre-releases. If you don't 
remember to disable the updates-testing repo, you get untested packages. 
The latest version of cyrus-sasl that is in the stable repo is 
cyrus-sasl-gssapi-2.1.23-36.fc18.x86_64. The reason you can't get the 
debuginfo packages for cyrus-sasl is because the update was yanked from 
the testing repo due to *drumroll* segfaults.


I strongly recommend that you do the following:
'yum clean all' (Purges your yum cache completely, so we don't get stale 
data)
'yum update fedora-release' (The latest version that is now in stable 
disables updates-testing)
'yum distro-sync' (This upgrades and downgrades all packages so that 
they match what is in the enabled repositories, in this case it will 
guarantee that you have the latest stable versions of all packages).


Alternately you can wait until next week (January 8th) when Fedora 18 
stable is expected to be released (assuming that tomorrow's Go/No-Go 
meeting does not delay it for another week) and install fresh from there.


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] sssd cache

[Stephen Gallagher]

On Fri 16 Nov 2012 08:56:59 AM EST, Natxo Asenjo wrote:

On Fri, Nov 16, 2012 at 2:52 PM, Natxo Asenjo  wrote:

hi,

when running getent negroup  I get old entries.
Apparently sssd is being helpful :-) and caching info, but it should
not do it when I am connected to the domain (IMHO).

According to 
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache.html
I can clean records with sss_cache, but this command is not available.


ahem ...

this is in sssd-tools, which is in the 2nd dvd iso which is not in my
local mirror (just the first one). Sorry for the noise.



Two points here. 1) sss_cache is moving to the main package in RHEL 
6.4, so you won't have to install the separate sssd-tools package for 
it. 2) You might also look at the manpage for 
entry_cache_netgroup_timeout. If you want to have a shorter timeout 
period for netgroups, you can set it individually (starting with SSSD 
1.8.0, IIRC). I'd suggest not setting it shorter than 10s for 
performance reasons though.


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo not working

[Stephen Gallagher]

On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote:

I'm pretty certain there's a painfully simple solution to this that
I'm not seeing, but my current configuration isn't picking up the
freeipa sudoer rule that I've set.

/etc/nsswitch.conf specifies:
 sudoers:files ldap

/etc/nslcd.conf contains:

binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me
bindpw password

ssl start_tls
tls_cacertfile /etc/ipa/ca.crt
tls_checkpeer yes

bind_timelimit 5
timelimit 15

uri ldap://fs1.wedgeofli.me 
sudoers_base ou=SUDOers,dc=wedgeofli,dc=me


The sssd_DOMAIN.log file contains this when I try to sudo:





The SSSD logs aren't showing anything wrong because they have nothing 
to do with the execution of the SUDO rules in this situation. All the 
SSSD is doing is verifying the authentication (when sudo prompts you 
for your password).


The problem with the rule is most likely happening inside SUDO itself. 
When you specify 'sudoers: files, ldap' in nsswitch.conf, it's telling 
SUDO to use its own internal LDAP driver to look up the rules. So you 
need to check sudo logs to see what's happening (probably you will need 
to enable debug logging in /etc/sudo.conf).


Recent versions of SUDO (1.8.6 and later) have support for setting 
'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0 and 
later) for lookups (and caching) of sudo rules.


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] User's choice: automount or autocreate?

[Stephen Gallagher]

On Wed 31 Oct 2012 08:56:14 AM EDT, Bret Wortman wrote:

Has anyone set things up so that individual users have the option to
automount a homedir or have one autocreated on each system they use
for them? I have some users who prefer one way and others who prefer
the other. Both have valid reasons and I'd rather not make an
authoritarian decision for one over the other.

 1. How could this be handled as a user option, set as the account is
created or modified and open to adjustment later?


A feature could be added to SSSD to allow users to override the home 
directory location on individual clients. This feature would have to be 
subject to administrator approval in some way (to restrict where users 
could set their home directories and which users have this privilege). 
That requires some thought. Feel free to file an RFE at 
https://fedorahosted.org/sssd



 2. How might this be handled as a login option, allowing the user to
select their automounted homedir or a local homedir?



This just isn't going to happen. Period.

The location of the user's home directory is an integral part of the 
user's identity on the system. It cannot vary at login time. All 
sessions of the logged-in user (as well as any application that calls 
getpwnam()) need to agree on this value or you will have problems.



Anyone already set this up and have it working well? I'd hate to spend
time re-inventing a wheel if there's already an excellent example in
the wild




As a general rule, it's usually better to just make the decision on a 
per-system basis than a per-user basis. I.e. everyone who logs on to 
certain infrastructure systems will always use the automount home 
directory, but on personal systems they can be configured to not use 
automount.


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] PAM / SSSD / HBAC

[Stephen Gallagher]

On Tue, 2012-08-28 at 17:21 -0400, Rob Crittenden wrote:
> Michael Mercier wrote:
> > On 2012-08-22, at 4:12 PM, Rob Crittenden wrote:
> >
> >> Michael Mercier wrote:
> >>> Hello,
> >>>
> >>> In Aug 2010, someone posted a message to this list about integrating
> >>> tacacs+ with freeipa
> >>> https://www.redhat.com/archives/freeipa-users/2010-August/msg00058.html
> >>>
> >>> At the time, it was mentioned that this was not on the roadmap, has this
> >>> changed?
> >>
> >> No, still not on the roadmap.
> >>
> >>
> >>> If RedHat has no plans to do this, where can I find the freeipa
> >>> documentation that would allow me to do a proof-of-concept?  I would use
> >>> the freely available tac_plus (http://www.shrubbery.net/tac_plus/) as a
> >>> staring point.
> >>
> >> http://freeipa.org/page/Contribute (in Developer Documentation and 
> >> Developement Process) and
> >> http://abbra.fedorapeople.org/freeipa-extensibility.html
> >>
> >>>
> >>> Some of the specific things I am looking for:
> >>> 1.  How should passwords be verified?  sssd, pam, ldap lookup, krb?
> >>> 2.  How the ldap schema should be designed for best integration?
> >>
> >> I'd start by seeing if there is already one defined as a real or quasi 
> >> standard.
> >>
> >>> 3.  The proper way to query the ldap server (standard ldap calls or is
> >>> there some specific freeipa api)
> >>
> >> Standard LDAP calls.
> >>
> >>> 4.  I am sure I am not asking something!!
> >>>
> >>> I tried asking some similar questions on freeipa-devel but didn't
> >>> receive a response.
> >>
> >> rob
> >
> > Hello,
> >
> > I have started playing with having the tac_plus daemon use Freeipa and have 
> > some questions regarding HBAC.
> >
> > I have done the following:
> >
> > 1.  Created a DNS entry for my device:  pix.beta.local <-> 192.168.0.1
> > 2.  Disabled the 'allow_all' HBAC rule
> > 3.  Created an HBAC rule tacacs with the following:
> >a) who: user group: ciscoadmin - user mike is part of ciscoadmin
> >b) Accessing: hosts: pix.beta.local
> >c) via service: tac_plus
> >d) from: any host
> >
> > I can successfully login (auth) to a Cisco ASA via the tac_plus daemon 
> > using PAM.  I have added some code to also attempt to do PAM accounting for 
> > the device and can't get this to work.
> >
> > Aug 28 16:13:34 ipaserver tac_plus[2217]: pam_sss(tac_plus:auth): 
> > authentication success; logname=root uid=0 euid=0 tty= ruser= 
> > rhost=192.168.0.1 user=mike
> > Aug 28 16:13:34 ipaserver tac_plus[2217]: pam_sss(tac_plus:account): Access 
> > denied for user mike: 6 (Permission denied)
> >
> > If I add the host (ipaserver.beta.local) the daemon is running on to the 
> > 'Accessing' list or enable the 'allow_all' rule, I am able to login.
> >
> > I see the following in my audit.log
> > type=USER_AUTH msg=audit(1346184814.834:168): user pid=2217 uid=0 auid=0 
> > ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
> > msg='op=PAM:authentication acct="mike" 
> > exe="/home/tacacs/tacacs+-F4.0.4.26/.libs/lt-tac_plus" hostname=192.168.0.1 
> > addr=192.168.0.1 terminal=pts/0 res=success'
> > type=USER_ACCT msg=audit(1346184814.845:169): user pid=2217 uid=0 auid=0 
> > ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
> > msg='op=PAM:accounting acct="mike" 
> > exe="/home/tacacs/tacacs+-F4.0.4.26/.libs/lt-tac_plus" hostname=192.168.0.1 
> > addr=192.168.0.1 terminal=pts/0 res=failed'
> >
> > It seems that the machine the daemon is running on is being used for the 
> > HBAC rule (at least that is what is looks like from the dirsrv access log)
> > [28/Aug/2012:16:13:33 -0400] conn=29 op=45 SRCH 
> > base="cn=hbac,dc=beta,dc=local" scope=2 
> > filter="(&(objectClass=ipaHBACRule)(ipaEnabledFlag=TRUE)(|(hostCategory=all)(memberHost=fqdn=ipaserver.beta.local,cn=computers,cn=accounts,dc=beta,dc=local)))"
> >  attrs="objectClass cn ipaUniqueID ipaEnabledFlag accessRuleType memberUser 
> > userCategory memberService serviceCategory sourceHost sourceHostCategory 
> > externalHost memberHost hostCategory"
> >
> > Is it possible to get the 'hostname' (pix.beta.local/192.168.0.1) passed 
> > through to HBAC?
> > It looks like the 'msg' portion of the audit data is coming from PAM (Is 
> > this correct)?
> > Should I be posting this to the devel list instead?
> >
> 
> An educated guess would be that the tac_plus daemon would need to be 
> modified to send the requesting server hostname to PAM.

SSSD doesn't support source host processing because it was an impossible
feature to implement properly. PAM provides a srchost attribute, but
specifies no requirements for what it should contain. It may contain:
 * The remote host's hostname as offered by that remote host - This
cannot be trusted, as the remote host may be lying. Potential security
issue.
 * The remote host's IP address - this would necessitate us doing an
rDNS lookup and trying every possible hostname that is returned, which
exposes us to DNS poisoning attacks. Potential security

Re: [Freeipa-users] FreeIPA, rkhunter & "unknown rootkit"

[Stephen Gallagher]

On Fri, 2012-08-17 at 13:42 -0500, Anthony Messina wrote:
> On Monday, July 23, 2012 04:08:25 AM Anthony Messina wrote:
> > I have installed freeipa-server-2.2.0-1.fc17.x86_64 and it's running
> > well.  I have also installed rkhunter-1.4.0-1.fc17.noarch on the IPA
> > server and each morning I receive the following report from rkhunter.
> > 
> > I imagine/hope that these are not actual rootkits and was wondering if
> > anyone knew of a way to inform rkhunter/rkhunter.conf to "never mind"
> > these as they seem like they would be a normal part of the IPA/CA process.
> > 
> > By the way, UID 995 is the pkiuser on my IPA system.
> > 
> > Thanks for any input. -A
> > 
> > 
> > rkhunter warning output follows:
> > 
> > Warning: The following processes are using suspicious files:
> >  Command: java
> >UID: 995PID: 1513
> >Pathname: /var/log/pki-ca/system
> >Possible Rootkit: Unknown rootkit
> >  Command: java
> >UID: 1518PID: 1513
> >Pathname: 14287633
> >Possible Rootkit: Unknown rootkit
> 
> Is anyone able to offer some insight on this one?  Perhaps there is some way 
> to undate the rkhunter configuration to 'allow' this behavior, if it's 
> intended.  Thanks.  -A


This looks to me like it's a false positive. Please file a bug against
the rkhunter package at bugzilla.redhat.com


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] sssd client cache timer and merging IPA domains

[Stephen Gallagher]

On Fri, 2012-08-17 at 11:42 +0200, Jakub Hrozek wrote:
> On Thu, Aug 16, 2012 at 09:00:23PM +, Steven Jones wrote:
> > Hi,
> > 
> > What is the default length of time the sssd daemon on a client caches for 
> > once IPA is off line pls?
> > 
> 
> If the IPA provider is offline, we never remove anything from the cache, so
> indefinitely.
> 

One exception: if you've opted to use the offline_credentials_expiration
option in sssd.conf, then after the specified number of days, the user's
cached password (but none of his other information) will be removed from
the client.

> If the provider is online, we cache for 90 minutes by default, then
> refresh the entry.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] User can't login via ssh from external source

[Stephen Gallagher]

On Fri, 2012-07-20 at 15:21 -0400, Dmitri Pal wrote:
> On 07/20/2012 03:03 PM, Joe Linoff wrote: 
> When you set the password on the server using the ipa passwd command
> you make it know to the admin. This is why it is right away expired
> and requires a change.
> A user needs to log in through the client that allows changing the
> password as a part of the authentication.
> It looks like your ssh is not configured to do password change (I
> suspect it uses GSSAPI but I might be wrong).
> So either the ssh needs to be configured to do the password change
> over the pam stack or you need to login as this user and change his
> password and then you will be able to ssh.

To clarify, what you need to do is make sure that the following options
are set in /etc/ssh/sshd_config:

UsePAM yes
PasswordAuthentication no
KerberosAuthentication no
GSSAPIAuthentication yes
ChallengeResponseAuthentication yes


This should hopefully resolve the issue for you.

Note: KerberosAuthentication is NOT the same as disabling the
single-sign-on. That's done by GSSAPIAuthentication.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA and UIDS <500

[Stephen Gallagher]

On Thu, 2012-07-19 at 16:44 +0100, Innes, Duncan wrote:
> Does this mean that it's impossible to have IPA authenticate the
> oracle user or any other user that is normally below 500?
> 
> Our security team is asking that we manage the passwords of oracle and
> other users centrally.  Can IPA do this for me?

It's not impossible, but it requires some mangling of your PAM stacks
in /etc/pam.d/*

That said, it's generally a bad idea to have passwords on users < 500.
It should not be possible to log into them at all, and instead you
should rely on granting (restricted) sudo privileges to real users
allowing them to impersonate the service user instead.

So instead of allowing people to log into the box as 'oracle', they
should log in as 'myusername' and then run 'sudo -u oracle '.
This provides better auditing support as well, since you will always
know which real user modified your database configuration (rather than
trying to piece together who logged in as 'oracle' directly).


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA and UIDS <500

[Stephen Gallagher]

On Thu, 2012-07-19 at 00:53 +, Steven Jones wrote:
> Actually its pamunless IPA is as well.
> 
> Which makes sense then to have an application run < 500 so inherently it 
> cannot be logged into via ssh

Well, it's possible to configure your system to allow logging in to
users below 500, but it's not recommended. The real risk is of having
system services with an ID that conflicts with a user.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] a user called oracle

[Stephen Gallagher]

On Thu, 2012-07-19 at 00:39 +, Steven Jones wrote:
> Hi,
> 
> I want to create a user that users who can login to a host can sudo -i 
> tobut I dont want to allow that  user ssh or login but must exist on the 
> server such that the sudo -i command will succeed.
> 
> I cannot see how this is done, can it be done?

Set their shell to /bin/nologin


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA and UIDS <500

[Stephen Gallagher]

On Thu, 2012-07-19 at 00:02 +, Steven Jones wrote:
> Hi,
> 
> Is there a rule or something that makes users with a UID of less than
> 500 not work? 


Yes, on Red Hat and older Fedora systems, UIDs below 500 are reserved
for system services such as the apache user.

On newer Fedora systems (and most other distributions such as Debian and
Ubuntu), the reserved range has been increased to 1000.

So it's never safe to use an ID below those values. (And as a general
rule, it's best to keep your network IDs above 10,000 to avoid conflicts
with local user accounts as well).


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] rfe: ldap for dhcp

[Stephen Gallagher]

On Tue, 2012-06-26 at 15:02 +0200, Natxo Asenjo wrote:
> hi,
> 
> recently it was brought to my attendtion that isp-dhcpd version 4.2
> supports getting its database information from ldap. Earlier versions
> support it as well with a patch.
> 
> It would be awesome if this could be integrated in IPA.
> 
> I am aware you guys have your hands full with plenty of stuff, but if
> this could get integrated IPA would be even further than AD (that as
> far as I know cannot do this).

Natxo, would you be interested in contributing this functionality? If
you are familiar with Python, an excellent primer on FreeIPA development
can be found at http://abbra.fedorapeople.org/guide.html

The core FreeIPA team has a lot on their plate right now, so any major
new features like this would probably need to be contributed from wider
community or else deferred until the current crop of functionality is
complete.

We'd be happy to help you along if you (or anyone else on this mailing
list) wants to take this feature on.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Transfer user database to FreeIPA LDAP

[Stephen Gallagher]

On Mon, 2012-06-25 at 15:39 -0400, Dmitri Pal wrote:
> On 06/25/2012 02:36 PM, Simo Sorce wrote:
> > On Mon, 2012-06-25 at 13:51 -0400, Dmitri Pal wrote:
> >> Simo are you sure simple bind is enough? I thought that it should be a
> >> bind over SSL with some specific ext op. Do I recall it wrong? 
> > A bind over SSL is still called a "simple bind" and simply mean a bind
> > that users a plain text password, the other option is a "SASL bind".
> >
> > We use SASL binds when using Krb credentials for example to do a
> > SASL/GSSAPI/Krb5 bind.
> >
> > We could also use a SASL/PLAIN bind, but I think there is a bug in 389DS
> > with SASL/PLAIN, there should be a ticket somewhere. But it is not
> > important, SASL/PLAIN is almost never used.
> >
> > Simo.
> >
> I know that it is called a simple bind. But it is not just a simple
> bind. It needs to be a bind over SSL and I recall some ext op being
> required too but I am not sure and this is what I was asking about.
> 

This is incorrect. The migration is handled as a plugin on the DS side.
So when a simple bind occurs, it checks to see if the user binding has
kerberos entries. If not, it takes the plaintext and creates the entry.
If migration mode is enabled on the server, it will do this
automatically (If the user does not already have kerberos hashes).

The presence or absence of SSL is irrelevant, but it is always wise to
use SSL, since the LDAP protocol transmits the simple bind password in
plaintext over the wire, making it trivial to snoop without TLS/SSL in
place.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa and gdm

[Stephen Gallagher]

On Mon, 2012-06-25 at 11:09 -0700, george he wrote:
> Hi Stephen,
> 
> 
> Here are the lines from /var/log/messages. it seems there's some info,
> but I don't understand it...
...
> Jun 25 14:03:53 mz dbus-daemon[775]: dbus[775]: [system] Rejected send
> message, 2 matched rules; type="method_return", sender=":1.0" (uid=0
> pid=728 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)"
> member="(unset)" error name="(unset)" requested_reply="0"
> destination=":1.21" (uid=42 pid=1183 comm="/usr/bin/gnome-session -f
> ")
> Jun 25 14:03:53 mz dbus[775]: [system] Rejected send message, 2
> matched rules; type="method_return", sender=":1.0" (uid=0 pid=728
> comm="/usr/lib/systemd/systemd-logind ") interface="(unset)"
> member="(unset)" error name="(unset)" requested_reply="0"
> destination=":1.21" (uid=42 pid=1183 comm="/usr/bin/gnome-session -f
> ")

This is probably the cause of the issue, but I don't know why it's
happening. Someone who understands GDM and systemd better than I do
would have to step in here.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa and gdm

[Stephen Gallagher]

On Mon, 2012-06-25 at 10:55 -0700, george he wrote:
> Hi Stephen,
> selinux was set to permissive before I installed the client. ( I
> modified the file /etc/sysconfig/selinex)


Modifying that file without a reboot does not change the current state.
That only tells the kernel whether to boot with SELinux enabled.

I suggest looking at /var/log/messages for other possible failures as
well. From /var/log/secure, SSSD is authenticating successfully, so the
failure is happening in GDM somewhere.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa and gdm

[Stephen Gallagher]

On Mon, 2012-06-25 at 10:41 -0700, george he wrote:
> Hi Stephen,
> 
> 
> I already have a home directory which was created the first time I ssh
> in.
> Now when I click on "sign in", nothing happens...
> 

Just to experiment, try 'setenforce 0' as root and then try to log in.
SELinux could be denying you.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa and gdm

[Stephen Gallagher]

On Mon, 2012-06-25 at 10:25 -0700, george he wrote:
> Hello Stephen,
> 
> 
> this is what in the log file:
> 
> Jun 25 13:22:10 mz gdm-password][21545]: pam_unix(gdm-password:auth):
> authentication failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser=
> rhost=  user=jhe
> Jun 25 13:22:11 mz gdm-password][21545]: pam_sss(gdm-password:auth):
> authentication success; logname=(unknown) uid=0 euid=0 tty=:0 ruser=
> rhost= user=jhe


According to that, SSSD successfully authenticated the user, but you
still didn't get logged in? I'll bet that means you don't have your
system set up to create home directories on first login automatically.

If you run ipa-client-install with the --mkhomedir option when
configuring the client, it will set this up for you. If you want to
change it after the fact, do this:

authconfig --update --enable-mkhomedir

That should do the trick.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa and gdm

[Stephen Gallagher]

On Mon, 2012-06-25 at 09:52 -0700, george he wrote:
> Hello,
> I have a server and a few client set up. I can ssh to the server or
> clients. But there's no entry on the console gdm for ipa user, and I
> cannot login by choosing "others" either.
> What do I need to set up for gdm log on? I searched the docs but
> didn't find any...


Entries do not appear on the GDM login until you have logged in at least
once by choosing "others". I'm concerned that this is not working,
however.

Can you do
'tail -n0 -f /var/log/secure' in a root shell while attempting to log in
through GDM and then show us what it says?

Also, please tell us what version of SSSD is installed on your system
(you can find out with 'rpm -q sssd')



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Transfer user database to FreeIPA LDAP

[Stephen Gallagher]

On Sun, 2012-06-24 at 15:10 -0700, Joe Linoff wrote:
> Hi Mark:
> 
>  
> 
> I did not find any entries related to passwords in the LDAP record.
> There were some entries that looked as though they were related to
> Kerberos which might be useful.
> 
> % ldapseach -LLL -x -b
> "uid=bigbob,cn=users,cn=accounts,dc=example,dc=com" | grep ^krb
> 
> krbPwdPolicyReference:
> cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=sw,dc=
> 
> krbPrincipalName: big...@example.com
> 
> krbLastPwdChange: 20120530170153Z
> 
> krbPasswordExpiration: 20120828170153Z
> 
> krbExtraData:: AAgBAA==
> 
> krbExtraData:: AAKBUsZPc3Nob3J0QFNXLlRBQlVMQS5DT00A
> 
> krbLastSuccessfulAuth: 20120621180658Z
> 
> krbLastFailedAuth: 20120620013218Z
> 
> krbLoginFailedCount: 0
> 
>  
> 
> Unfortunately, I am new to IPA so I don’t yet understand the internals
> for password management. Can you suggest any documentation I can read?
> I am fairly familiar with LDAP and Kerberos.


You do not need to populate the Kerberos password fields directly. Once
you migrate your DB users to LDAP, if you enable IPA's "migration
mode" (see the docs on how), the next time a user binds to LDAP using
their existing password, a pre-bind plugin on FreeIPA will catch the
plaintext password and use it to populate the Kerberos password fields
automatically.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] odd cron behaviour

[Stephen Gallagher]

On Fri, 2012-06-15 at 15:19 +0200, Sigbjorn Lie wrote:
> Hi,
> 
> I've seen cron jobs on some of our machines not being run after they we're 
> migrated to IPA. The
> machines in question has not been restarted after they we're migrated from 
> NIS to IPA.
> 
> These are RHEL 6 machines. The users that has the crontab that's not run, was 
> in NIS, and the same
> account having the same UID/GID exists in IPA. Cron jobs for local accounts 
> run as they did before
> migrating to IPA.
> 
> Jun 15 13:53:01 hostname crond[1810]: (username) ORPHAN (no passwd entry)
> 
> Restarting the cron daemon solves the issue, and the cron jobs immediately 
> starts running again.
> 
> Has anyone else seen this issue?


Running daemons cannot pick up changes to /etc/nsswitch.conf. They have
to be restarted. This is a long-standing bug in glibc (well, the glibc
upstream doesn't consider it a bug, but their users do).


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] ipa client - turn off NetworkManager?

[Stephen Gallagher]

On Mon, 2012-06-11 at 12:25 -0400, Dmitri Pal wrote:
> On 06/09/2012 06:24 AM, Joe Linoff wrote: 
> > Hi:
> > 
> >  
> > 
> > I read somewhere that I should turn off the NetworkManager service
> > on the IPA server. Should I do same on the clients?
...
> 
> There was a problem with earlier versions which now is addressed for
> quite some time.


Just for clarity, do you mean that there were issues with early SSSD
(which there were, and have long been fixed; years now) or do you mean
that Network Manager now works reasonably with FreeIPA as well?


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Administration question: root user

[Stephen Gallagher]

On Wed, 2012-06-06 at 06:59 -0700, Joe Linoff wrote:
> Hi Folks:
> 
>  
> 
> I am a newbie so I apologize in advance if this is a silly set of
> questions. I am using FreeIPA 2.1.3 on CentOS 6.2 and am very happy
> with it but I have a couple of questions about root access. When I
> setup my systems, I configured root manually on each of them. 
> 
>  
> 
> Does it make sense to define the root user in FreeIPA?

No, this is unsafe. You always want to be able to log in locally as root
if something goes wrong. We specifically exclude 'root' from being
managed by SSSD for this reason.

> 
>  
> 
> Is it desirable from a security and administration perspective? 

Absolutely not. Your better bet would be to maintain SUDO rules on each
of the systems instead.

> 
>  
> 
> If it does make sense, is it as simple as adding the “root” user in
> “ipa user-add”?

Please don't :)



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] FreeIPA 2.1 - restrict users to a set of hosts

[Stephen Gallagher]

On Mon, 2012-06-04 at 08:39 +0200, Martin Kosek wrote:
> On Sat, 2012-06-02 at 06:52 -0700, Joe Linoff wrote:
> > Hi:
> > 
> >  
> > 
> > I am a newbie that is trying out FreeIPA for the first time. So far I
> > am extremely impressed with this system but I ran into a problem that
> > I need some help with. I am trying to figure out how to HBAC to
> > restrict a set of users to a specific set of hosts but I am not having
> > any success.
> > 
> >  
> > 
> > Here is the problem statement:
> > 
> >  
> > 
> > I have 2 users: “user1” and “user2” that should only be able to access
> > the host “foobar” on my network. There are many other possible hosts
> > (like “wombat”) that they cannot access. They can login from anywhere
> > using “ssh”. 
> > 
> >  
> > 
> > The goal is to restrict students to a specific set of machines.
> > 
> >  
> > 
> > What I tried to do was this:
> > 
> >  
> > 
> > 1.  Create a user group called “restricted-users” which I could
> > add users to.
> > 
> > 2.  Create a HBAC rule named “restricted-users” that
> > 
> > a.  Defines the host I want to allow them access to
> > (“restricted-host”).
> > 
> > b.  Defines the user group that is affected by this rule
> > (“restricted-users”).
> > 
> > c.  Defines the services they are allowed to use on that host
> > (including login).
> > 
> > 3.  Create a user named “user1” that is enrolled in the
> > “restricted-users” group.
> > 
> >  
> > 
> > I then tried this experiment:
> > 
> >  
> > 
> > 1.  ssh –Y user1@foobar
> > 
> > a.  It worked like a charm. The login worked correctly.
> > 
> > 2.  ssh –Y user1@wombad
> > 
> > a.  It also worked like a charm but in this case it was undesired
> > behavior.
> > 
> >  
> > 
> > I am sure that I am missing something really obvious. Any help would
> > be greatly appreciated.
> > 
> >  
> > 
> > Errata:
> > 
> > 1.  OS: CentOS 6.2
> > 
> > 2.  FreeIPA: v2.1.3 (9el6)
> > 
> >  
> > 
> > Thank you,
> > 
> >  
> > 
> > Joe
> > 
> 
> Hello Joe,
> 
> did you disable default allow_all HBAC rule?
> 
> # ipa hbacrule-show allow_all
>   Rule name: allow_all
>   User category: all
>   Host category: all
>   Source host category: all
>   Service category: all
>   Description: Allow all users to access any host from any host
>   Enabled: TRUE
> 
> With this rule disabled, the policy you described should be properly
> enforced. When testing HBAC rules you may want to try CLI and Web UI
> interface to hbactest command, which can help you to test who can use
> what service on which machine and also which rules did match when the
> access was allowed.


If you're still experiencing problems after disabling the default
allow_all rule, please submit the relevant section of /var/log/secure so
we can see if anything peculiar is occurring in the PAM authentication
and authorization.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] New mailing list: sssd-users

[Stephen Gallagher]

For quite some time, we have used the sssd-devel mailing list for
development and user configuration issue discussions. As the project has
grown, it becomes more and more clear that we need to separate these
topics into their own lists.

So as of today, we now have a new mailing list for user questions. You
can subscribe at https://fedorahosted.org/mailman/listinfo/sssd-users

This list will be considerably less noisy for our users as they will not
be bombarded with patch review emails and other development-centric
issues.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] fail joining an ubuntu 12.04 to a freeipa server with ipa-client-install

[Stephen Gallagher]

On Fri, 2012-05-11 at 13:16 +0200, pasqual milvaques wrote:

> root : DEBUG Init ldap with: ldap://freeipaserver.linux.gva.es:389
> root : ERROR LDAP Error: Connect error: A TLS packet with unexpected 
> length was received.
> Failed to verify that freeipaserver.linux.gva.es is an IPA Server.
> This may mean that the remote server is not up or is not reachable
> due to network or firewall settings.


This error about the unexpected length can occur if your /etc/hosts file
lists the short version of the hostname before the long version, e.g.

192.168.0.1 freeipaserver freeipaserver.linux.gva.es

You want it to be:

192.168.0.1 freeipaserver.linux.gva.es freeipaserver


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] How to rebuild IPA master?

[Stephen Gallagher]

On Thu, 2012-05-10 at 00:24 +, Steven Jones wrote:
> Hi,
> 
> In case everyone else is asleep now..
> 
> Do you have access to RH documentation?  the 6.3beta admin guide
> section 18.8 talks about why and how to make a replicate a master.

The problem seems to be that David had only a single server providing
the dogtag CA, and that was the machine that died.

> 
>  I've a IPA master/replica setup in our development environment.
> Unfortunately our IPA master crashed, the replica is working fine. Now
> I have the IPA master re-imaged.
> 
> 
>  What are the steps I have to follow to re-create the IPA master from
> running IPA replica? Before crash the IPA master ran dogtag
> certificate system, while the IPA replica didn't  -- created normally
> without the --setup-ca option.

You'll have to check with the FreeIPA/Dogtag dev team (I'm a client-side
guy, so I don't have all the data here), but you're probably not going
to be in good shape. If you kept a separate backup of the private root
certificate for the CA, you may be able to stand up a new CA instance
and then issue new signed certs from the restored private root cert.
Otherwise, you're probably in trouble.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Unable to login to some clients if one of the IPA servers is down.

[Stephen Gallagher]

On Tue, 2012-05-01 at 20:41 +, Steven Jones wrote:
> Which sssd.conf's?


On the clients that you cannot log into.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeIPA bug: Kerberos clients fails taking to IPA server after ipa-client-install

[Stephen Gallagher]

On Mon, 2012-04-30 at 14:51 -0700, David Copperfield wrote:
> 
> Hi folks,
> 
>  During migration existing Kerberos/LDAP setup clients to IPA, after
> 'ipa-client-install' command is run and reports successful migration,
> we found that the client fails to talk with IPA server.
> 
>  The symptom is: in the /var/log/messages file at IPA client side, we
> can see the following entries:
> 
> Apr 30 11:07:04 ldapclient02 sssd: Starting up
> Apr 30 11:07:05 ldapclient02 sssd[be[pegaclouds.com]]:
> Starting up
> Apr 30 11:07:06 ldapclient02 sssd[pam]: Starting up
> Apr 30 11:07:06 ldapclient02 sssd[nss]: Starting up
> Apr 30 11:07:06 ldapclient02 [sssd[ldap_child[2133]]]: Failed
> to initialize credentials using keytab [(null)]: Decrypt integrity
> check failed. Unable to create GSSAPI-encrypted LDAP connection.
> 
>  It is figured out that, instead of backup and
> overwrite /etc/krb5.keytab, ipa-client-install only appends the new
> generated host keytab entries to the same file /etc/krb5.keytab. Then
> when the original entries have a higher KVNO version than the newly
> generated siblings, the latter is shadowed and ignored.
>
> 
>  After manual removing the old entries from /etc/krb5.keytab with the
> tool ktutil (rkt, delent, wkt), the client immdiately connects to IPA
> server and problem goes away. It will be greatly appreciated if native
> ipa-rmkeytab can be extended to do the same job. 
> 


Actually, this was a bug in SSSD that has now been fixed in the RHEL 6.3
beta. It's related to https://bugzilla.redhat.com/show_bug.cgi?id=805281

Please give that a try and see if it resolves your issue.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Unable to login to some clients if one of the IPA servers is down.

[Stephen Gallagher]

On Mon, 2012-04-30 at 22:14 +, Steven Jones wrote:
> Hi,
> 
> Do you want me to open a RH case?
> 


Yes, that's probably best. Please include as much detail as possible,
such as your sssd.conf and, ideally, a sanitized sssd_DOMAINNAME.log at
level 6 or higher.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Password migrating into IPA with SSSD failed

[Stephen Gallagher]

> 
> The existing document states all the steps as listed below.
> 
> A user tries to log into a machine with SSSD. 
> SSSD attempts to perform Kerberos authentication against the
> IPA server. 
> Even though the user exists in the system, the authentication
> will fail with the error key type is not supported because the
> Kerberos hashes do not yet exist. 
> SSSD the performs a plaintext LDAP bind over a secure
> connection. 
> IPA intercepts this bind request. If the user has a Kerberos
> principal but no Kerberos hashes, then the IPA identity
> provider generates the hashes and stores them in the user
> entry. 
> If authentication is successful, SSSD disconnects from IPA and
> tries Kerberos authentication again. This time, the request
> succeeds because the hash exists in the entry. 
> The steps 4-6 are a little difficult to understand: Are these steps
> SSSD/IPA's internal information exchange mechanism? or do I have to
> setup something at IPA client/server side to fullfill? like setup
> pam_ldap or nslcd/nss_ldap?
> 


Steps 4-6 are handled automatically by SSSD as long as it is configured
with 'id_provider = ipa' and 'auth_provider = ipa' (which is how
ipa-client-install configures it) and migration mode is enabled on the
server.

> 
> I've mirgated all my users and groups from openLDAP into IPA without
> user password/hash ( another bug here: needs
> --group-objectclas='posixGroup' option, and optionally
> --schema='RFC2307'), the passwords were not migrated, and so I tried
> the above method to setup new passwords seamlessly for users,
> unfortunately all tries failed.
> 

This is the problem. In order for seamless password migration to work,
you need to migrate the hashes. If we cannot bind with the old password,
we can't set that up for Kerberos.

What it sounds like you probably want to do (since you aren't keeping
the hashes) is just reset the passwords for all of your users, which
will require them to change it on first login. There's an admin command
'ipa passwd ' that can reset a user password. There may also
be tools to do this in bulk, but someone else will need to chime in
here.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Unable to login to some clients if one of the IPA servers is down.

[Stephen Gallagher]

On Sun, 2012-04-29 at 23:37 +, Steven Jones wrote:
> Hi,
> 
> Maybe I am missing something here but I thought/assumed that if one of
> teh IPA servers was off line the client would use the other IPA
> server?
> 
> This doesnt seem to be the case, so am I wrong on how IPA works, or do
> I have a setup error?


We're looking into it. Someone else reported a similar issue on Friday.
We may have introduced a regression in the failover logic of SSSD.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Problem: How to download the keytab from IPA without resetting/regenerating a new one??

[Stephen Gallagher]

On Thu, 2012-04-26 at 19:58 -0700, David Copperfield wrote:
> Hi,
> 
> 
>  Just have a silly case where I've to download the existing version
> keytab for a service principal. It is download only -- not recreate a
> new version and download the new version which ipa-getkeytab does. --
> ipa-getkeytab command name seems a little bit misleading because it
> does both 'set' and 'get' operations. 

Well, this is actually intentional. I'm curious what your reasoning is
for wanting to access the original key. There really isn't any downside
to just pulling a brand-new one for a host, and the upside is that you
just rolled your keys, so if they happened to be compromised, you're
safe now.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA clashing with selinux on users home directories

[Stephen Gallagher]

On Thu, 2012-03-08 at 20:14 +, Steven Jones wrote:
> Hi,
> 
> I am setting up some IPA users what I have noticed is if I or they type
> startx to start a gui locking the .Xauthority fails, if I setenforce 0
> then it works fine.I have never seen this behaviour before and
> googling suggests its an IPA and selinux conflict.
> 
> and in fact when I create a local user they get an instant gui from
> running startx...
> 

I'm guessing you're creating your home directories with the help of
pam_mkhomedir.so. This won't work with SELinux. You need to install and
use pam_oddjob_mkhomedir.so instead, which will properly set up SELinux
contexts for your users.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] SSSD (sssd_be) crashing on RHEL 6.2

[Stephen Gallagher]

On Fri, 2012-03-02 at 15:20 +0100, Sigbjorn Lie wrote:
> On Fri, March 2, 2012 15:16, Stephen Gallagher wrote:
> > On Fri, 2012-03-02 at 15:08 +0100, Sigbjorn Lie wrote:
> >
> >> On Fri, March 2, 2012 15:04, Stephen Gallagher wrote:
> >>
> >>> On Fri, 2012-03-02 at 14:52 +0100, Sigbjorn Lie wrote:
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>>
> >>>>
> >>>> I'm experiencing that SSSD is now crashing at random times on _ALL_ RHEL 
> >>>> 6.2 machines where
> >>>> we have installed SSSD connected to an IPA domain. SSSD can reach up to 
> >>>> a month of uptime
> >>>> before sssd_be crashes. This happens on both physical and virtual 
> >>>> machines. It happens at
> >>>> different machines at different times, sometimes during working hours, 
> >>>> other times during
> >>>> the middle of the night. It's never happened on several machines at the 
> >>>> same time.
> >>>>
> >>>> These machines does not have a GUI and the issue is similar but not 
> >>>> directly related to the
> >>>> KDE
> >>>> screensaver lock as per my earlier posts. Also, the KDE screensaver 
> >>>> issue was at RHEL 5.
> >>>>
> >>>> What happens is a line in the syslog about sssd_be crashing.
> >>>>
> >>>>
> >>>>
> >>>> sssd_be[1418] general protection ip:41d527 sp:7fff9e82ead0 error:0 in 
> >>>> sssd_be[40+4a000]
> >>>>
> >>>>
> >>>> sssd_be is then being restarted by the parent process, but is no longer 
> >>>> usable. Any login
> >>>> via ssh to these machines will just hang.
> >>>>
> >>>> Has anyone else seen this issue?
> >>>>
> >>>>
> >>>
> >>>
> >>> Can you try to get us a backtrace, please? "general protection" isn't
> >>> enough information. Though it's interesting that it's "general 
> >>> protection" and not
> >>> "segfault"...
> >>> That's certainly new.
> >>>
> >>>
> >>>
> >>> Do you have abrtd running on these systems? If so, it should be able to
> >>> capture a core dump when this happens again, which you can use to 
> >>> generate a backtrace for us.
> >>>  ___
> >>>
> >>
> >> I certainly do have abrt, some of the dumps are quite large. I will send 
> >> you these in a private
> >>  email.
> >>
> >
> >
> > Thanks, can you also let me know the exact version of SSSD that you're
> > running?
> >
> 
> Sure.
> 
> sssd-1.5.1-66.el6.x86_64
> sssd-client-1.5.1-66.el6.x86_64

I've opened https://fedorahosted.org/sssd/ticket/1226 to track the crash
you're seeing. All three of the backtraces you sent me had the same
information (included in the ticket; it contains no private data).

This is only happening during "graceful" shutdown when sssd_be receives
a SIGTERM and is cancelling all pending requests. It's possible that the
actual behavior you're seeing is unrelated to this crash, though.
Because a crash at shutdown (or restart) should still be properly
recovering.

This is a serious issue though, so let's get this out of the picture and
see what else happens after that.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] SSSD (sssd_be) crashing on RHEL 6.2

[Stephen Gallagher]

On Fri, 2012-03-02 at 15:08 +0100, Sigbjorn Lie wrote:
> On Fri, March 2, 2012 15:04, Stephen Gallagher wrote:
> > On Fri, 2012-03-02 at 14:52 +0100, Sigbjorn Lie wrote:
> >
> >> Hi,
> >>
> >>
> >> I'm experiencing that SSSD is now crashing at random times on _ALL_ RHEL 
> >> 6.2 machines where we
> >> have installed SSSD connected to an IPA domain. SSSD can reach up to a 
> >> month of uptime before
> >> sssd_be crashes. This happens on both physical and virtual machines. It 
> >> happens at different
> >> machines at different times, sometimes during working hours, other times 
> >> during the middle of
> >> the night. It's never happened on several machines at the same time.
> >>
> >> These machines does not have a GUI and the issue is similar but not 
> >> directly related to the KDE
> >>  screensaver lock as per my earlier posts. Also, the KDE screensaver issue 
> >> was at RHEL 5.
> >>
> >> What happens is a line in the syslog about sssd_be crashing.
> >>
> >>
> >> sssd_be[1418] general protection ip:41d527 sp:7fff9e82ead0 error:0 in 
> >> sssd_be[40+4a000]
> >>
> >> sssd_be is then being restarted by the parent process, but is no longer 
> >> usable. Any login via
> >> ssh to these machines will just hang.
> >>
> >> Has anyone else seen this issue?
> >>
> >
> >
> > Can you try to get us a backtrace, please? "general protection" isn't
> > enough information. Though it's interesting that it's "general protection" 
> > and not "segfault"...
> > That's certainly new.
> >
> >
> > Do you have abrtd running on these systems? If so, it should be able to
> > capture a core dump when this happens again, which you can use to generate 
> > a backtrace for us.
> > ___
> 
> I certainly do have abrt, some of the dumps are quite large. I will send you 
> these in a private
> email.
> 


Thanks, can you also let me know the exact version of SSSD that you're
running?


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] SSSD (sssd_be) crashing on RHEL 6.2

[Stephen Gallagher]

On Fri, 2012-03-02 at 14:52 +0100, Sigbjorn Lie wrote:
> Hi,
> 
> I'm experiencing that SSSD is now crashing at random times on _ALL_ RHEL 6.2 
> machines where we
> have installed SSSD connected to an IPA domain. SSSD can reach up to a month 
> of uptime before
> sssd_be crashes. This happens on both physical and virtual machines. It 
> happens at different
> machines at different times, sometimes during working hours, other times 
> during the middle of the
> night. It's never happened on several machines at the same time.
> 
> These machines does not have a GUI and the issue is similar but not directly 
> related to the KDE
> screensaver lock as per my earlier posts. Also, the KDE screensaver issue was 
> at RHEL 5.
> 
> What happens is a line in the syslog about sssd_be crashing.
> 
> sssd_be[1418] general protection ip:41d527 sp:7fff9e82ead0 error:0 in 
> sssd_be[40+4a000]
> 
> sssd_be is then being restarted by the parent process, but is no longer 
> usable. Any login via ssh
> to these machines will just hang.
> 
> Has anyone else seen this issue?


Can you try to get us a backtrace, please? "general protection" isn't
enough information. Though it's interesting that it's "general
protection" and not "segfault"... That's certainly new.

Do you have abrtd running on these systems? If so, it should be able to
capture a core dump when this happens again, which you can use to
generate a backtrace for us.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA & hostnames. Why not use `hostname -fqdn` instead of forcing `hostname` to be fully qualified?

[Stephen Gallagher]

On Fri, 2012-03-02 at 05:16 +0300, Craig T wrote:
> Hi,
> 
> Server Side:
> RHEL6.2
> ipa-admintools-2.1.3-9.el6.x86_64
> ipa-client-2.1.3-9.el6.x86_64
> ipa-pki-ca-theme-9.0.3-7.el6.noarch
> ipa-pki-common-theme-9.0.3-7.el6.noarch
> ipa-python-2.1.3-9.el6.x86_64
> ipa-server-2.1.3-9.el6.x86_64
> ipa-server-selinux-2.1.3-9.el6.x86_64
> 
> 
> Client Side Config:
> Centos 6.2
> ipa-client-2.1.3-9.el6.x86_64
> ipa-python-2.1.3-9.el6.x86_64
> 
> 
> Issue:
> IPA (via sssd) requires that a hostname (as returned by the `hostname`
> commmand) be fully qualified.
> 
> This requirement has caused us no end of grief due to ripple effects not
> related to IPA, it breaks other software we use which expects hostname
> to be not fully qualified.
> 
> We don't understand why IPA & sssd require that a machine's hostname be
> fully qualified when `hostname --fqdn` can be used instead?
> 
> In our case we had hostname setup to be the machine name as in:
> 
> # hostname
> foo
> # dnsdomainname
> bar.com.au
> # hostname --fqdn
> foo.bar.com.au
> 
> Why doesn't IPA & SSD use the value returned by `hostname --fqdn`?
> 
> Why must `hostname` itself be fully qualified when `hostname --fqdn` is
> available?

I think this requirement is only in place during ipa-client-install.
sssd.conf has an option 'ipa_hostname=foo.bar.com.au' which it will use
regardless of the value that 'hostname' returns.

Is there some other place I'm missing? If so, that's probably a bug and
should be reported as such.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA, samba, and secondary groups

[Stephen Gallagher]

On Wed, 2012-02-29 at 13:49 -0500, Kelvin Edmison wrote:
> 
> 
> On 12-02-29 1:40 PM, "Stephen Gallagher"  wrote:
> 
> > On Wed, 2012-02-29 at 11:24 -0500, Kelvin Edmison wrote:
> >> Hi all,
> >> 
> >>  I am running into an issue where users cannot access a samba volume if
> >> their only access is via a secondary group.  For example, if testuser's
> >> primary group is ipausers, and secondary groups include testgroup, and the
> >> samba mount permissions are adminuser:testgroup:rwxrwx---, then testuser
> >> cannot read or write to the samba mount.  If the testuser is change so that
> >> its primary group is testgroup, then testuser can access the volume.
> >> 
> >> In this case, samba is running on a separate CentOS 5 server, configured to
> >> access IPA via LDAP.  It is a requirement that I support
> >> userid/password-based access to the samba server, as I cannot roll all my
> >> users onto kerberos right away.
> >> 
> >> Doe anyone have any insight as to what is going on and how it can be fixed?
> > 
> > 
> > First step would be to make sure that the system is properly looking up
> > the user's secondary groups.
> > 
> > Try 'id testuser' and see if 'testgroup' is listed in the output. If
> > it's not, I'll bet you have either a configuration issue or a bug in
> > SSSD somewhere.
> > 
> > Also, what version of SSSD are you running? FreeIPA pretty much needs
> > 1.5.x or later nowadays for full feature support.
> 
> 'id testuser' returns gid=ipausers and groups=ipausers,testgroup.
> 
> SSSD RPM is sssd-1.5.1-37.el5
> 
> I'm no samba expert so it's quite possible I may have botched setup in that
> arena.


One more question: was the user added to "testgroup" after logging in?
Does logging out and logging back in resolve the problem? In Linux,
users are only assigned their groups at login time. They don't ever
change memberships until a new session.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA, samba, and secondary groups

[Stephen Gallagher]

On Wed, 2012-02-29 at 11:24 -0500, Kelvin Edmison wrote:
> Hi all,
> 
>  I am running into an issue where users cannot access a samba volume if
> their only access is via a secondary group.  For example, if testuser's
> primary group is ipausers, and secondary groups include testgroup, and the
> samba mount permissions are adminuser:testgroup:rwxrwx---, then testuser
> cannot read or write to the samba mount.  If the testuser is change so that
> its primary group is testgroup, then testuser can access the volume.
> 
> In this case, samba is running on a separate CentOS 5 server, configured to
> access IPA via LDAP.  It is a requirement that I support
> userid/password-based access to the samba server, as I cannot roll all my
> users onto kerberos right away.
> 
> Doe anyone have any insight as to what is going on and how it can be fixed?


First step would be to make sure that the system is properly looking up
the user's secondary groups.

Try 'id testuser' and see if 'testgroup' is listed in the output. If
it's not, I'll bet you have either a configuration issue or a bug in
SSSD somewhere.

Also, what version of SSSD are you running? FreeIPA pretty much needs
1.5.x or later nowadays for full feature support.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] devel repo

[Stephen Gallagher]

On Mon, 2012-02-27 at 22:05 -0800, Brian Cook wrote:
> example
> 
> 
> [root@ipasvr yum.repos.d]# yum list freeipa-server
> Loaded plugins: langpacks, presto, refresh-packagekit
> Available Packages
> freeipa-server.i686
> 2.1.4-1.20120209T0216Zgit11c25a4.fc16 ipa-devel
> freeipa-server.x86_64 2.1.4-5.fc16
>updates  
> [root@ipasvr yum.repos.d]# 

This is happening because the upstream repo has the same version in the
sources as what's in Fedora (this is why I always bump the version
number for SSSD to the next release as soon as I build a tarball). Then
the ipa-devel repo would be guaranteed to match as "newer" than what is
in the standard repositories.

In other words, the FreeIPA git sources should be producing
2.1.5-0.20120209T0216Zgit11c25a4.fc16 instead of 2.1.4-1 (which is less
than 2.1.4-5.fc16 as yum reckons things).

In the meantime, you should be able to work around this by doing 'yum
install freeipa-server-2.1.4-1.20120209T0216Zgit11c25a4.fc16.x86_64' (I
think).

Of course, if the version number has changed since you originally sent
this, do the yum search again. Note that you have to expressly
say .x86_64 when specifying the package to install.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] FreeIPA 2.2 alpha or beta available somewhere?

[Stephen Gallagher]

On Fri, 2012-02-10 at 22:30 +0100, Marco Pizzoli wrote:
> 
> 
> On Fri, Feb 10, 2012 at 10:18 PM, John Dennis 
> wrote:
> On 02/10/2012 03:49 PM, Marco Pizzoli wrote:
> --> Finished Dependency Resolution
> *Error: Protected multilib versions:
> libldb-1.1.0-1.fc16.i686 !=
> libldb-1.1.4-1.fc16.1.x86_64*
> 
> This error is because you've got both a 32-bit and 64-bit
> version of libldb installed, note how the 32-bit version is
> 1.1.0 and the 64-bit version is 1.1.4, they're not the same.
> 
> Actually I think the situation is a little bit different. 
> 
> To explain myself better I start by posting this output:
> 
> [root@freeipa02 ~]# rpm -qa|grep libldb
> libldb-1.1.0-1.fc16.x86_64
> 
> Look for a second at the output i posted before. As you can see 
> 
> [cut]
> --> Running transaction check
> ---> Package libldb.i686 0:1.1.0-1.fc16 will be installed
> [cut]
> 
> The package libldb-32bit is being submitted to yum as a candidate from
> a dependence on a package situated in your ipa-devel repository. 
> 
> I'm not a yum expert, can you confirm what I notice?
> 
>  
> However the ipa-devel repo does have both the 32-bit and
> 64-bit version of 1.1.4 available in the x86-64 repo
> 
> ipa-devel/fedora/16/x86_64/os/libldb-1.1.4-1.fc16.1.i686.rpm
> ipa-devel/fedora/16/x86_64/os/libldb-1.1.4-1.fc16.1.x86_64.rpm
> 
> So the repo looks good, not sure what yum is complaining
> about, it should see both 32-bit and 64-bit is available for
> version 1.1.4 and install both, unless of course you've got a
> dependency on the 1.1.0 32-bit version, but yum should tell
> you that.
> 
> That's about as much help as I can give you at the moment.


You're right. I see what's happening. SSSD is built with an explicit LDB
dependency. So because it's keeping SSSD at 1.6.4 for you, it's trying
to hang on to libldb 1.1.0 from the regular repos (which is
inappropriate).

The real question here is why it's not pulling in the latest SSSD bits.
And the answer to that is because we're currently having issues where
not all of the SSSD subpackages are ending up in the repo. So yum is
trying its best with what it has (which doesn't line up).

We're working on this. We'll have it fixed by sometime on Monday, I'm
sure.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] FreeIPA 2.2 alpha or beta available somewhere?

[Stephen Gallagher]

On Fri, 2012-02-10 at 16:18 -0500, John Dennis wrote:
> On 02/10/2012 03:49 PM, Marco Pizzoli wrote:
> > --> Finished Dependency Resolution
> > *Error: Protected multilib versions: libldb-1.1.0-1.fc16.i686 !=
> > libldb-1.1.4-1.fc16.1.x86_64*
> 
> This error is because you've got both a 32-bit and 64-bit version of 
> libldb installed, note how the 32-bit version is 1.1.0 and the 64-bit 
> version is 1.1.4, they're not the same.
> 
> However the ipa-devel repo does have both the 32-bit and 64-bit version 
> of 1.1.4 available in the x86-64 repo
> 
> ipa-devel/fedora/16/x86_64/os/libldb-1.1.4-1.fc16.1.i686.rpm
> ipa-devel/fedora/16/x86_64/os/libldb-1.1.4-1.fc16.1.x86_64.rpm
> 
> So the repo looks good, not sure what yum is complaining about, it 
> should see both 32-bit and 64-bit is available for version 1.1.4 and 
> install both, unless of course you've got a dependency on the 1.1.0 
> 32-bit version, but yum should tell you that.

SSSD has to be built against a specific version of LDB. It's not
compatible with mixed-versions in your install. Also, yum SHOULD have
prevented installing different versions of libldb in multilib. I'm not
sure why it didn't.

So with all that said, the easiest thing to do would be to 'yum remove
libldb.i686' and then try updating again.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] FreeIPA 2.2 alpha or beta available somewhere?

[Stephen Gallagher]

On Fri, 2012-02-10 at 10:50 +0100, Marco Pizzoli wrote:
> Hi,
> 
> On Mon, Jan 30, 2012 at 4:55 PM, Dmitri Pal  wrote:
> On 01/30/2012 09:47 AM, Marco Pizzoli wrote: 
> > Hi guys,
> > Next days I'm going to start a test deployment of FreeIPA
> > 2.1 but the following days I'm planning to have a look on
> > the new features FreeIPA 2.2 brings.
> > 
> > Are you going to release a alpha/beta package anytime in the
> > future?
> > 
> > Thanks in advance
> > Marco
> > 
> > -- 
> > 
> > 
> > 
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> Yes alpha is planned for next couple weeks.
> 
> 
> 
> Sorry for asking again, but I'm really interested in this. 
> Any news on the expected release date? I'm available to test it and
> give feedbacks, once released.

If you're interested in testing the nightly builds, you can install one
of the below repository files into /etc/yum.repos.d

Fedora 15-17:
http://jdennis.fedorapeople.org/ipa-devel/ipa-devel-fedora.repo

RHEL 6:
http://jdennis.fedorapeople.org/ipa-devel/ipa-devel-rhel.repo


Then you can 'yum update' to the latest nightlies.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD

[Stephen Gallagher]

On Wed, 2012-02-08 at 12:23 +0100, Sigbjorn Lie wrote:
> On Sat, February 4, 2012 14:58, Stephen Gallagher wrote:
> > On Fri, 2012-02-03 at 12:53 +0100, Sigbjorn Lie wrote:
> >
> >> On Wed, February 1, 2012 15:04, Simo Sorce wrote:
> >>
> >>> On Wed, 2012-02-01 at 07:28 -0500, Stephen Gallagher wrote:
> >>>
> >>>
> >>>> On Wed, 2012-02-01 at 11:02 +0100, Sigbjorn Lie wrote:
> >>>>
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>>
> >>>>>
> >>>>> Is this more like the expected output? :)
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> No, I'm afraid it's not. That's a log of a legitimate shutdown, not a
> >>>> segmentation fault. (Receiving SIGTERM means that the monitor told the 
> >>>> process to exit).
> >>>>
> >>>> Possibly this happened if the time between attaching to the process and
> >>>> typing 'cont' was more than about 30 seconds. The monitor will assume 
> >>>> the sssd_be process
> >>>> isn't responding and will kill and restart it.
> >>>>
> >>>> You will know you got the correct results if you see
> >>>>
> >>>>
> >>>>
> >>>> "Program received signal SIGSEGV, Segmentation fault."
> >>>>
> >>>>
> >>>>
> >>>> and then you can immediately perform the 'bt full'
> >>>
> >>> For better results with gdb I suggest to kill SIGSTOP the monitor before
> >>> attaching gdb to any of the reponders or the providers, this way the 
> >>> monitor will be prevented
> >>> from sending termination signals to the children. However, don't do this 
> >>> for long, only for
> >>> short periods and kill SIGCONT back the monitor immediately after.
> >>>
> >>>
> >>
> >> Please see below. Does this help?
> >>
> >
> > Yes, thank you it does.
> >
> >
> >>
> >>
> >> (gdb) bt full
> >> #0  sysdb_attrs_get_el_int (attrs=0x6c616d726f6e2d72, name=0x43c75d "name",
> >> alloc=true, el=0x7fffe9e0dab8) at src/db/sysdb.c:254 e =  >> out> i =  >> optimized out> #1  0x004221d7 in sysdb_attrs_primary_name 
> >> (sysdb=0xf725e00,
> >> attrs=0x6c616d726f6e2d72, ldap_attr=0xf741110 "cn",
> >
> > The memory address for "attrs" here is WAY out of range. That suggests
> > that this is an uninitialized value.
> >
> >> _primary=0x7fffe9e0db58) at src/db/sysdb.c:2441
> >> ret =  rdn_attr = 0x0 rdn_val = 0x0 sysdb_name_el = 
> >> 0x61 orig_dn_el =  >> optimized out> i =  tmpctx = 0xf768ce0 __FUNCTION__ =
> >> "sysdb_attrs_primary_name"
> >> #2  0x0042290d in sysdb_attrs_primary_name_list (sysdb=0xf725e00,
> >> mem_ctx=, attr_list=0xf772e20, attr_count=2, 
> >> ldap_attr=0xf741110 "cn",
> >> name_list=0x7fffe9e0dc88) at src/db/sysdb.c:2606 ret = 259427552 i = 1
> >
> > i = 1, so it's the second entry in the attr_list being passed in. My 
> > spidey-sense is tingling
> > here. Probably the array is one entry too long above.
> >
> >> j = 1 list =  name = 0xf769580 "ac_server-normal" 
> >> __FUNCTION__ =
> >> "sysdb_attrs_primary_name_list"
> >> #3  0x2b20c9684456 in sdap_initgr_nested_get_membership_diff (
> >> state=0xf7726f0) at src/providers/ldap/sdap_async_accounts.c:3061 
> >> __FUNCTION__ =
> >> "sdap_initgr_nested_get_membership_diff"
> >>
> >
> >
> > This is the function that is creating that array (well, actually it's
> > sdap_initgr_nested_get_direct_parents()). So the bug must be occurring 
> > here. We're somehow creating
> > an array of two entries but not populating the second one.
> >
> > That said, I'm not sure how that's possible. The code there is very
> > short and seems pretty carefully-written to avoid this possibility.
> >
> > I don't have time today to dig into this any further, but I wanted to
> > get my findings down in an email so that if anyone else wanted to jump on 
> > this before I get back to
> > it, they don't have to start from scratch.
> 
> 
> Hi,
> 
> Any progress on this?

We haven't forgotten about you, but we've been tied up dealing with the
1.8 beta. We're starting to look at the backlog of bugs now.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] acroread: unknown user id

[Stephen Gallagher]

On Tue, 2012-02-07 at 14:49 +0100, Sigbjorn Lie wrote:
> On Tue, February 7, 2012 12:32, Sumit Bose wrote:
> > On Tue, Feb 07, 2012 at 11:49:07AM +0100, Sigbjorn Lie wrote:
> >
> >> Hi,
> >>
> >>
> >> This error occurs when starting Acrobat Reader. This occured with version 
> >> 8, and I just
> >> downloaded AdobeReader_enu-9.4.7-1 to see if that would make a difference. 
> >> Same problem.
> >>
> >>
> >> This is a Red Hat 5 machine running sssd-1.5.1-44.el5.
> >>
> >>
> >> $ acroread
> >>
> >>
> >> (acroread:3349): GLib-WARNING **: getpwuid_r(): failed due to unknown user 
> >> id (12345)
> >>
> >>
> >> I'm logged on to the console of the machine, and typing "id" returns the 
> >> username for my uid,
> >> all my groups, etc. I have not experienced this issue with any other 
> >> applications yet.
> >>
> >> /etc/nsswitch.conf:
> >> passwd: files sss
> >> group:  files sss
> >> shadow: files sss
> >>
> >>
> >>
> >> Anyone seen this before?
> >>
> >
> > yes, I would expect that you run a 32bit acroread on a 64bit system. You 
> > have to install the 32bit
> > sssd-client packages as well.
> >
> > HTH
> >
> >
> 
> Ah, you are correct! Installing the i386 packages fixed the issue.
> 
> Perhaps the i386 rpm packages should be required by the x86_64 sssd rpm 
> packages to avoid any such
> issues?

There is a long-standing debate on how to handle this.

The problem is that requiring the i386 RPM packages means that the
system has to pull in the 32-bit versions of all its dependencies,
including glibc.i386. On systems that want to be purely 64-bit, we don't
want to force them to have all these extra pieces.

There are several bugs open in RPM and yum to try to figure out how to
solve this correctly. Unfortunately I can't locate the BZs right now.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD

[Stephen Gallagher]

On Fri, 2012-02-03 at 12:53 +0100, Sigbjorn Lie wrote:
> On Wed, February 1, 2012 15:04, Simo Sorce wrote:
> > On Wed, 2012-02-01 at 07:28 -0500, Stephen Gallagher wrote:
> >
> >> On Wed, 2012-02-01 at 11:02 +0100, Sigbjorn Lie wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>> Is this more like the expected output? :)
> >>>
> >>>
> >>
> >> No, I'm afraid it's not. That's a log of a legitimate shutdown, not a
> >> segmentation fault. (Receiving SIGTERM means that the monitor told the 
> >> process to exit).
> >>
> >> Possibly this happened if the time between attaching to the process and
> >> typing 'cont' was more than about 30 seconds. The monitor will assume the 
> >> sssd_be process isn't
> >> responding and will kill and restart it.
> >>
> >> You will know you got the correct results if you see
> >>
> >>
> >> "Program received signal SIGSEGV, Segmentation fault."
> >>
> >>
> >> and then you can immediately perform the 'bt full'
> >
> > For better results with gdb I suggest to kill SIGSTOP the monitor before
> > attaching gdb to any of the reponders or the providers, this way the 
> > monitor will be prevented from
> > sending termination signals to the children. However, don't do this for 
> > long, only for short
> > periods and kill SIGCONT back the monitor immediately after.
> >
> >
> 
> Please see below. Does this help?

Yes, thank you it does.

> 
> 
> (gdb) bt full
> #0  sysdb_attrs_get_el_int (attrs=0x6c616d726f6e2d72, name=0x43c75d "name",
> alloc=true, el=0x7fffe9e0dab8) at src/db/sysdb.c:254
> e = 
> i = 
> #1  0x004221d7 in sysdb_attrs_primary_name (sysdb=0xf725e00,
> attrs=0x6c616d726f6e2d72, ldap_attr=0xf741110 "cn",

The memory address for "attrs" here is WAY out of range. That suggests
that this is an uninitialized value.

> _primary=0x7fffe9e0db58) at src/db/sysdb.c:2441
> ret = 
> rdn_attr = 0x0
> rdn_val = 0x0
> sysdb_name_el = 0x61
> orig_dn_el = 
> i = 
> tmpctx = 0xf768ce0
> __FUNCTION__ = "sysdb_attrs_primary_name"
> #2  0x0042290d in sysdb_attrs_primary_name_list (sysdb=0xf725e00,
> mem_ctx=, attr_list=0xf772e20, attr_count=2,
> ldap_attr=0xf741110 "cn", name_list=0x7fffe9e0dc88) at src/db/sysdb.c:2606
> ret = 259427552
> i = 1

i = 1, so it's the second entry in the attr_list being passed in. My
spidey-sense is tingling here. Probably the array is one entry too long
above.

> j = 1
> list = 
> name = 0xf769580 "ac_server-normal"
> __FUNCTION__ = "sysdb_attrs_primary_name_list"
> #3  0x2b20c9684456 in sdap_initgr_nested_get_membership_diff (
> state=0xf7726f0) at src/providers/ldap/sdap_async_accounts.c:3061
> __FUNCTION__ = "sdap_initgr_nested_get_membership_diff"


This is the function that is creating that array (well, actually it's
sdap_initgr_nested_get_direct_parents()). So the bug must be occurring
here. We're somehow creating an array of two entries but not populating
the second one.

That said, I'm not sure how that's possible. The code there is very
short and seems pretty carefully-written to avoid this possibility.

I don't have time today to dig into this any further, but I wanted to
get my findings down in an email so that if anyone else wanted to jump
on this before I get back to it, they don't have to start from scratch.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Other distro clients

[Stephen Gallagher]

On Thu, 2012-02-02 at 10:44 -0500, Dmitri Pal wrote:
> On 02/02/2012 09:59 AM, Nigel Sollars wrote: 
> > Hi All, 
> > 
> > 
> > I notice online people have already asked about Clients for other
> > linux distributions,  my addition to this is how far ( if any )
> > along is the effort?.  Is there an svn / git repo I can grab
> > sources / test packages for say Debian or SuSE?.
> > 
> > 
> > Any info would be most welcomed
> > 
> > 
> 
> Some time ago SSSD was built for Suse. I am not sure it was
> maintained. I am not aware of any effort to port ipa-client to Suse.
> There is some effort to port ipa-client to Debian and Ubuntu but I do
> not know where the code for this is.

The port to Debian and Ubuntu is being spearheaded by Timo Aaltonen
(CCed). He has a PPA with a reasonably recent version of SSSD available
that can be used with FreeIPA v2.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA Sudo - RHEL5

[Stephen Gallagher]

On Wed, 2012-02-01 at 08:51 +0100, Westerlund Johnny wrote:
> Hey all,
> 
> I've been running IPA on a RHEL6.2 and so far it's looking great. HBAC
> is awsome. The other machines in the domain is another RHEL 6.2 and one
> RHEL 5.7.
> 
> I've also configured SUDO and it was working great on all machines. But
> thats changed now. The RHEL 6.2 and the ipaserver itself (also rhel6.2)
> works great. But the RHEL 5.7 stopped working the other day, and
> nothing i do can make it work again.
> 
> I've followed the documentation at:
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/sudo.html
> But i just cant seem to find the problem, so i'm starting to wonder if
> it broke when i patched the system the other day.
> 
> Both login and HBAC rules seem to work fine on the 5.7 box, but not
> SUDO.  I've tried running the sssd daemon interactivly and in debug
> mode (sssd -i -d6) but it's hard to know what to look for. Anyone able
> to give some troubleshooting tips?

SUDO support doesn't go through SSSD[1]. It uses its own internal LDAP
driver to talk to FreeIPA. So if you're suddenly having trouble there,
I'd look into the sudo package.



[1] This is a feature we're working on for Fedora and will be coming in
future versions of RHEL 6, but probably not for RHEL 5


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Firewalling IPA 2

[Stephen Gallagher]

On Wed, 2012-02-01 at 07:56 +0100, Jakub Hrozek wrote:
> On Wed, Feb 01, 2012 at 03:31:15PM +1100, Craig T wrote: > Hi, > > I'd
> like to restict which hosts have access to port 389 on the IPA server. 
> > How does SSSD connect to the IPA 2.x server for user name queries? I
> half expected it to need port 389 or 636 open on the server, but my
> testing is showing this is not the case.

> SSSD uses LDAP + SASL/GSSAPI for identity lookups. Authentication is
> Kerberos with the exception of client side password migration that does
> a one-time TLS bind.
> 
> Both SASL/GSSAPI and the TLS bind use port 389. We don't use ldaps://
> (which would be port 636 by default) in the IPA provider at all.
> 
> As per why your testing looked like port 389 does not need to be open, my
> guess is that SSSD simply returned entries from cache. Does an identity
> lookup (getent passwd admin) work when you remove or expire the caches
> and restart SSSD?

Yeah, I agree with Jakub. SSSD performs caching on the client side so
that if the FreeIPA server is unreachable for a time, it can still
return resutls locally. If the server is unavailable, the cached results
will never expire, so you can't just wait it out (or use the sss_cache
tool to any great effect).

In terms of your firewall rules, you only want to allow access on port
389 for your hosts. It's also worth noting that because SSSD clients
bind with their host entry, you can also opt to disable anonymous access
to the FreeIPA LDAP server for added security.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD

[Stephen Gallagher]

On Wed, 2012-02-01 at 11:02 +0100, Sigbjorn Lie wrote:
> Hi,
> 
> Is this more like the expected output? :)
> 

No, I'm afraid it's not. That's a log of a legitimate shutdown, not a
segmentation fault. (Receiving SIGTERM means that the monitor told the
process to exit).

Possibly this happened if the time between attaching to the process and
typing 'cont' was more than about 30 seconds. The monitor will assume
the sssd_be process isn't responding and will kill and restart it.

You will know you got the correct results if you see

"Program received signal SIGSEGV, Segmentation fault."

and then you can immediately perform the 'bt full'


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos

[Stephen Gallagher]

On Tue, 2012-01-31 at 21:03 +, Dale Macartney wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Simo
> 
> I have used oddjob in the past and it works a treat, however this was
> with ipa-client-install..
> 
> I was just dappling around with the script over diner and saw you were
> an author...
> 
> whenever I use the flag --mkhomedir with ipa-client-install, i get the
> wrong contexts on the home dirs...
> 
> I raised a bugzilla ticket just before I left the office. Bug *786223*
> .
> 
> I'll keep playing with it an see what I come across. I'll feed back if
> anything useful comes up.

Yeah, ipa-client-install just invokes 'authconfig --update
--enablemkhomedir'

Authconfig's GUI version will auto-detect the presence of
pam_oddjob_mkhomedir and prefer that over pam_mkhomedir, but it appears
the command-line version always configures pam_mkhomedir.

We need to get that fixed in authconfig.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD

[Stephen Gallagher]

On Tue, 2012-01-31 at 13:35 +0100, Sigbjorn Lie wrote:
> 
> 
> Ok, please see below for the output from gdb.
> 
> I notice that it's not happening every time. All this morning I could unlock 
> without any issues.
> Around lunchtime the issue started occouring again, but it's different each 
> time how many times I
> have to restart sssd before I can successfully unlock my desktop.
> 
> 
> 
> warning: no loadable sections found in added symbol-file system-supplied DSO 
> at
> 0x7fff3fbfd000
> 0x2b104670cce3 in __epoll_wait_nocancel () from /lib64/libc.so.6
> (gdb) cont
> Continuing.
> 
> Detaching after fork from child process 22008.
> Detaching after fork from child process 23608.
> Detaching after fork from child process 28122.
> Detaching after fork from child process 32315.
> 
> Program received signal SIGSEGV, Segmentation fault.
> sysdb_attrs_get_el_int (attrs=0x6c616d726f6e2d72, name=0x43c75d "name",
> alloc=true, el=0x7fff3fafbb18) at src/db/sysdb.c:254
> 254 for (i = 0; i < attrs->num; i++) {
> (gdb)
> Continuing.

Don't do "continue" here. This is where we needed the 'bt full'. Once
you continue from here, it just exits and we lose the state.

Please rerun this test.

> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> The program no longer exists.
> (gdb) bt full
> No stack.
> (gdb)
> 
> 
> Regards,
> Siggi
> 
> 




signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos

[Stephen Gallagher]

On Tue, 2012-01-31 at 10:22 +0100, Ondrej Valousek wrote:
> 
> > > Hey sounds good to me, just glad it is working for you :). The only
> > > other question/suggestion I have is that it looks like you aren't
> > > leveraging kerberos in your configuration for SSO, You might want to
> > > think about doing this as it can be a pretty nice configuration.
> > > 
> > > Essentially you would just need to add service principles for the host
> > > in the form of imap and or pop, and change the auth line in your dovecot
> > > config to allow for gssapi auth, like so:
> > > 
> > > sed -i -r "s&(\smechanisms =).*&\1 gssapi plain&"
> > > 
> > > Then assuming your user has a ticket, and their client is properly
> > > configured, they no longer need to do anything upon logging into their
> > > system, kerb will auth the rest.
> > > 
> > > If you are on a multihomed system, you will need two additional changes,
> > > service principles for the other host name, and the following 
> > > modification:
> > > sed -i -r 's&#auth_gssapi_hostname.*&auth_gssapi_hostname = $ALL&'
> > > 
> > > I got a little caught up when you referenced the /etc/krb5.keytab file
> > > as possibly part of the problem so I thought this was more a kerb issue.
> > > 
> Exactly, I was confused by this as well - I would like to see this
> working, too. But I would say we would need to do something with the
> permissions on /etc/krb5.keytab which is now (by default) only
> readable by root. We need to address this problem more in general as
> when inegrating Bind DNS server, you hit the same thing.
> I would say something like ACL entry would help.


I fail to see why non-root processes should be trying to
read /etc/krb5.keytab at all. You should be generating a per-service
keytab with only the keys necessary for that service to authenticate
itself to the KDC. So you might have /etc/dovecot/dovecot.keytab which
is readable only by the dovecot user.

The problem with allowing access to /etc/krb5.keytab is that it means
that an exploit in another process (especially a mail server!) could
gain access to the keys necessary to impersonate your host in kerberized
applications on the network. That's really dangerous.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD

[Stephen Gallagher]

On Mon, 2012-01-30 at 18:00 +0100, Sigbjorn Lie wrote:
> Sure. Ive left the office for today, will do so tomorrow.
> 
> Im not very familiar with gdb. Any particular syntax / switches to
> add?
> 
> Rgds,
> Siggi.

You'll want to do this in a non-graphical terminal, so you can switch to
it if KDE gets into trouble.

First, install the sssd-debuginfo packages (debuginfo-install sssd)
and install gdb (yum install gdb)

Then run:
gdb -p ($pidof sssd_be)

Then in the gdb prompt, type 'cont' (this will resume execution of
sssd_be).

Now, switch back to KDE and unlock the screen. Then switch back to this
virtual terminal.

You should be back at the prompt, with GDB telling you that you received
a SIGSEGV or SIGABRT.

Type "bt full" and reply with all pages of output from that (there may
be multiple, requiring you to hit enter to see them).


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD

[Stephen Gallagher]

On Mon, 2012-01-30 at 16:01 +0100, Sigbjorn Lie wrote:
> Hi,
> 
> I'm doing a pre-implementation project for a customer having RHEL 5.7 
> workstations with KDE as
> their windows manager.
> 
> When using KDE at a RHEL 5.7 (or 5.8 BETA) workstation connected to a IPA 
> 2.1.3 running at RHEL
> 6.2 server, sssd will crash every time I attempt to unlock the screen.
> 
> To work around the issue I switch to tty1, log in as root, and restart sssd. 
> After attempting this
> several times (2-5 times), I can finally unlock the screen. I have attempted 
> to update one
> workstation to 5.8 beta to see if the issue was resolved there. No such luck.
> 
> Is this a known issue?
> 
> 
> The log displays the following:
> 
> Jan 30 15:49:16 svg118 kdesktop_lock: on 0
> Jan 30 15:49:21 svg118 kernel: sssd_be[9873] general protection rip:41dc3d 
> rsp:7fffc57c9f10 error:0
> Jan 30 15:49:22 svg118 sssd[be[no.ep.corp.local]]: Starting up
> Jan 30 15:49:33 svg118 sssd[be[no.ep.corp.local]]: Shutting down
> Jan 30 15:49:33 svg118 sssd[pam]: Shutting down
> Jan 30 15:49:33 svg118 kcheckpass[9896]: Authentication failure for username 
> (invoked by uid 12345)
> Jan 30 15:49:33 svg118 sssd[nss]: Shutting down
> Jan 30 15:49:33 svg118 sssd: Starting up
> Jan 30 15:49:34 svg118 sssd[be[no.ep.corp.local]]: Starting up
> Jan 30 15:49:34 svg118 sssd[nss]: Starting up
> Jan 30 15:49:34 svg118 sssd[pam]: Starting up
> Jan 30 15:49:42 svg118 kernel: sssd_be[9928] general protection rip:41dc3d 
> rsp:7fff70baba70 error:0
> Jan 30 15:49:43 svg118 sssd[be[no.ep.corp.local]]: Starting up
> Jan 30 15:49:52 svg118 sssd[be[no.ep.corp.local]]: Shutting down
> Jan 30 15:49:52 svg118 sssd[pam]: Shutting down
> Jan 30 15:49:52 svg118 kcheckpass[9933]: Authentication failure for username 
> (invoked by uid 12345)
> Jan 30 15:49:52 svg118 sssd[nss]: Shutting down
> Jan 30 15:49:52 svg118 sssd: Starting up
> Jan 30 15:49:52 svg118 sssd[be[no.ep.corp.local]]: Starting up
> Jan 30 15:49:52 svg118 sssd[pam]: Starting up
> Jan 30 15:49:52 svg118 sssd[nss]: Starting up
> Jan 30 15:49:59 svg118 kernel: sssd_be[9985] general protection rip:41dc3d 
> rsp:7fff40912260 error:0
> 

Definitely not a known issue. Do you think you could attach gdb to the
sssd_be process and try to get a backtrace for me to look at, please?


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Fedora 16 client not getting group names

[Stephen Gallagher]

On Mon, 2012-01-30 at 10:02 -0500, Dan Scott wrote:
> On Mon, Jan 30, 2012 at 09:46, Stephen Gallagher  wrote:
> > On Mon, 2012-01-30 at 09:41 -0500, Dan Scott wrote:
> >> Hi,
> >>
> >> On Mon, Jan 30, 2012 at 08:19, Stephen Gallagher  
> >> wrote:
> >> > On Fri, 2012-01-27 at 15:00 -0500, Dan Scott wrote:
> >> >> On Fri, Jan 27, 2012 at 13:17, Stephen Gallagher  
> >> >> wrote:
> >> >> > On Fri, 2012-01-27 at 17:57 +0100, Jakub Hrozek wrote:
> >> >> >> On Fri, Jan 27, 2012 at 11:47:01AM -0500, Dan Scott wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > On Fri, Jan 27, 2012 at 10:48, Stephen Gallagher 
> >> >> >> >  wrote:
> >> >> >> > > On Fri, 2012-01-27 at 10:36 -0500, Dan Scott wrote:
> >> >> >> > >> Hi,
> >> >> >> > >>
> >> >> >> > >> I have a Fedora 16 client running 
> >> >> >> > >> sssd-client-1.6.4-1.fc16.x86_64.
> >> >> >> > >>
> >> >> >> > >> When I run, e.g. id djscott, I do not get the names of the 
> >> >> >> > >> groups:
> >> >> >> > >>
> >> >> >> > >> -bash-4.2$ id djscott
> >> >> >> > >> uid=768(djscott) gid=1002(legacy-group)
> >> >> >> > >> groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,78961(ipausers),1102,1109,1129,
> >> >> >> > >>
> >> >> >> > >> Is this because they have low GIDs? (These were migrated over 
> >> >> >> > >> from my
> >> >> >> > >> old FreeIPA 1 installation and I'd rather not re-number them 
> >> >> >> > >> all).
> >> >> >> > >>
> >> >> >> > >> Can someone help me to figure out how to retrieve the group 
> >> >> >> > >> names?
> >> >> >> > >> This is working fine on the Fedora 15 clients (sssd-1.5.x).
> >> >> >> > >
> >> >> >> > >
> >> >> >> > > This looks to me like you didn't migrate all of the groups. GIF 
> >> >> >> > > 1002 and
> >> >> >> > > 78961 are both reporting the names correctly, so clearly the 
> >> >> >> > > client
> >> >> >> > > is able to access the FreeIPA server and retrieve groups.
> >> >> >> >
> >> >> >> > It's working fine with Fedora 15 clients, so I think that the 
> >> >> >> > groups
> >> >> >> > were migrated OK.
> >> >> >> >
> >> >> >> > > Please try the following and report the results:
> >> >> >> > >
> >> >> >> > > getent group 1134
> >> >> >> > >
> >> >> >> > > and also
> >> >> >> > > getent group 
> >> >> >> > >
> >> >> >> > > where  is the name that is SUPPOSED to match GID 1134.
> >> >> >> >
> >> >> >> > I've just realised that once I've manually looked up the group 
> >> >> >> > using
> >> >> >> > the name, the id command is 'fixed':
> >> >> >> >
> >> >> >> > [root@newton ~]# getent group 1134
> >> >> >> > [root@newton ~]# getent group svn-wfdb-swig-matlab
> >> >> >> > svn-wfdb-swig-matlab:*:1134:ikaro,djscott
> >> >> >> > [root@newton ~]# getent group 1134
> >> >> >> > svn-wfdb-swig-matlab:*:1134:ikaro,djscott
> >> >> >> > [root@newton ~]# id djscott
> >> >> >> > uid=768(djscott) gid=1002(legacy-group)
> >> >> >> > groups=1002(legacy-group),1134(svn-wfdb-swig-matlab),1130,1118,1103,1108,1113,78961(ipausers),1102,1109,1129,
> >> >> >> >
> >> >> >> > The initial getent returned no data. But the group info seems OK 
> >> >> >> > once
> >> >> >> > I've done one lookup.
> >> >> >> >
> >> 

Re: [Freeipa-users] FreeIPA Ubuntu Client

[Stephen Gallagher]

On Sat, 2012-01-28 at 17:22 +, Ranjandas A P wrote:
> Hi All,
> 
> Is there anybody who is woking on packaging IPA Client for Ubuntu
> 10.04? 
> 
> I am trying to build ipa-client for Ubuntu but, stuck with Mozldap
> dependency.


Timo Aaltonen has been working on this. (CCed).


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available

[Stephen Gallagher]

On Fri, 2012-01-27 at 13:42 -0500, Rob Crittenden wrote:
> 
> This came up yesterday internally too. I don't believe a bug or ticket 
> has been filed yet.
> 
> My best guess on what is happening, based on what I saw with our own 
> case, is this:
> 
> A migrated attribute is coming in that IPA doesn't know about. We 
> default to treating all attributes that don't require special treatment 
> (like binary values) as utf-8. I'm guessing that an unknown binary 
> attribute is being migrated, we try to utf-8 encode it and kablooey.
> 
> There is no easy workaround for the above problem right now because that 
> happens before the --ignore* options are considered.
> 

Why don't we just base64-encode unknown attributes instead of treating
them like UTF-8? The LDAP server is *supposed* to be able to handle this
implicitly.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Fedora 16 client not getting group names

[Stephen Gallagher]

On Fri, 2012-01-27 at 17:57 +0100, Jakub Hrozek wrote:
> On Fri, Jan 27, 2012 at 11:47:01AM -0500, Dan Scott wrote:
> > Hi,
> > 
> > On Fri, Jan 27, 2012 at 10:48, Stephen Gallagher  
> > wrote:
> > > On Fri, 2012-01-27 at 10:36 -0500, Dan Scott wrote:
> > >> Hi,
> > >>
> > >> I have a Fedora 16 client running sssd-client-1.6.4-1.fc16.x86_64.
> > >>
> > >> When I run, e.g. id djscott, I do not get the names of the groups:
> > >>
> > >> -bash-4.2$ id djscott
> > >> uid=768(djscott) gid=1002(legacy-group)
> > >> groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,78961(ipausers),1102,1109,1129,
> > >>
> > >> Is this because they have low GIDs? (These were migrated over from my
> > >> old FreeIPA 1 installation and I'd rather not re-number them all).
> > >>
> > >> Can someone help me to figure out how to retrieve the group names?
> > >> This is working fine on the Fedora 15 clients (sssd-1.5.x).
> > >
> > >
> > > This looks to me like you didn't migrate all of the groups. GIF 1002 and
> > > 78961 are both reporting the names correctly, so clearly the client
> > > is able to access the FreeIPA server and retrieve groups.
> > 
> > It's working fine with Fedora 15 clients, so I think that the groups
> > were migrated OK.
> > 
> > > Please try the following and report the results:
> > >
> > > getent group 1134
> > >
> > > and also
> > > getent group 
> > >
> > > where  is the name that is SUPPOSED to match GID 1134.
> > 
> > I've just realised that once I've manually looked up the group using
> > the name, the id command is 'fixed':
> > 
> > [root@newton ~]# getent group 1134
> > [root@newton ~]# getent group svn-wfdb-swig-matlab
> > svn-wfdb-swig-matlab:*:1134:ikaro,djscott
> > [root@newton ~]# getent group 1134
> > svn-wfdb-swig-matlab:*:1134:ikaro,djscott
> > [root@newton ~]# id djscott
> > uid=768(djscott) gid=1002(legacy-group)
> > groups=1002(legacy-group),1134(svn-wfdb-swig-matlab),1130,1118,1103,1108,1113,78961(ipausers),1102,1109,1129,
> > 
> > The initial getent returned no data. But the group info seems OK once
> > I've done one lookup.
> > 
> 
> That's weird, id runs getgrgid() on each of the returned group GIDs
> 

I know what's going on here. It was a stupid glibc screw-up in Fedora
16. Remove the line starting with "initgroups: " from
your /etc/nsswitch.conf file.

See https://bugzilla.redhat.com/show_bug.cgi?id=751450 for more details.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Fedora 16 client not getting group names

[Stephen Gallagher]

On Fri, 2012-01-27 at 10:36 -0500, Dan Scott wrote:
> Hi,
> 
> I have a Fedora 16 client running sssd-client-1.6.4-1.fc16.x86_64.
> 
> When I run, e.g. id djscott, I do not get the names of the groups:
> 
> -bash-4.2$ id djscott
> uid=768(djscott) gid=1002(legacy-group)
> groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,78961(ipausers),1102,1109,1129,
> 
> Is this because they have low GIDs? (These were migrated over from my
> old FreeIPA 1 installation and I'd rather not re-number them all).
> 
> Can someone help me to figure out how to retrieve the group names?
> This is working fine on the Fedora 15 clients (sssd-1.5.x).


This looks to me like you didn't migrate all of the groups. GIF 1002 and
78961 are both reporting the names correctly, so clearly the client
is able to access the FreeIPA server and retrieve groups.

Please try the following and report the results:

getent group 1134

and also
getent group 

where  is the name that is SUPPOSED to match GID 1134.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available

[Stephen Gallagher]

On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote:
> Hi
> 
> The first naming context returned from the LDAP server is always chosen
> when using migrate-ds. This makes my import fail when I attempt to
> import users and groups from a previous LDAP server having more than 1
> naming contexts available.
> 
> The migrate-ds script should accept an option to specify what base_dn I
> would like to import from.
> 
> Is there such an option today? I cannot find it...

Just to add to this request, if the original LDAP server has a
defaultNamingContext attribute, it should be honored for auto-detecting
which base to migrate.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Using DHCPD with IPA

[Stephen Gallagher]

On Tue, 2012-01-24 at 20:11 -0600, ~Stack~ wrote:
> > You can manage to have machines still fetch data from IPA, but they
> > can't be full fledged clients if you can't preserve the keytab and some
> > other configuration.
> 
> As long as I can have a user log into the box and run a process, I don't
> really care if they are a full client or not. Theses systems are never
> logged into directly, but through a ssh connection so if the users can
> still authenticate into them I might be good on this. How do I configure
> this?

You can set the clients up as pure LDAP+KRB5 clients in SSSD, but the
catch is that you lose the ability to configure them with HBAC rules.
(You need to do more traditional forms of access-control logic in that
case).

Only fully-enrolled clients will honor HBAC rules at this time.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers

[Stephen Gallagher]

On Fri, 2012-01-20 at 18:41 +0100, Sigbjorn Lie wrote:
> On 01/20/2012 06:33 PM, Stephen Gallagher wrote:
> > On Fri, 2012-01-20 at 17:35 +0100, Sigbjorn Lie wrote:
> >> On 01/19/2012 04:33 PM, Stephen Gallagher wrote:
> >>> On Thu, 2012-01-19 at 14:06 +, Charlie Derwent wrote:
> >>>> https://fedorahosted.org/freeipa/ticket/22827
> >>> For the record, the correct link is
> >>> https://fedorahosted.org/freeipa/ticket/2282
> >>>
> >>>
> >> The Solaris LDAP client has a property called servers, and a property
> >> called preferred servers. As the name implies, all the preferred servers
> >> will be used before using the rest of the servers in the servers
> >> property for that client.
> >>
> >> Perhaps this would be a good idea to implement in SSSD too?
> > https://fedorahosted.org/sssd/ticket/1128
> >
> > Currently scheduled for SSSD 1.9.0 (end of May)
> >
> Excellent! :)
> 
> In the ticket is mentioned "server", a single server. Will this feature 
> be implemented of a single primary server, or a group of 
> primary/preferred servers?
> 

The original intent was to handle switching back over to the primary
server when failover caused an error. However, please add your request
to that ticket and it'll be evaluated there.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers

[Stephen Gallagher]

On Fri, 2012-01-20 at 17:35 +0100, Sigbjorn Lie wrote:
> On 01/19/2012 04:33 PM, Stephen Gallagher wrote:
> > On Thu, 2012-01-19 at 14:06 +, Charlie Derwent wrote:
> >> https://fedorahosted.org/freeipa/ticket/22827
> > For the record, the correct link is
> > https://fedorahosted.org/freeipa/ticket/2282
> >
> >
> 
> The Solaris LDAP client has a property called servers, and a property 
> called preferred servers. As the name implies, all the preferred servers 
> will be used before using the rest of the servers in the servers 
> property for that client.
> 
> Perhaps this would be a good idea to implement in SSSD too?

https://fedorahosted.org/sssd/ticket/1128

Currently scheduled for SSSD 1.9.0 (end of May)


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers

[Stephen Gallagher]

On Thu, 2012-01-19 at 14:06 +, Charlie Derwent wrote:
> https://fedorahosted.org/freeipa/ticket/22827

For the record, the correct link is
https://fedorahosted.org/freeipa/ticket/2282



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers

[Stephen Gallagher]

On Thu, 2012-01-19 at 13:18 +, Charlie Derwent wrote:
> Thanks for the advice Stephen (and the quick response), obviously that
> won't help with load balanced comms during the installation process
> but it should keep it to a minimum afterwards. 
> 
> Wouldn't a quick solution be the addition of a "--primary" flag to the
> ipa-client-install script? It could behave in the same way as the
> --server flag and be a substitute for it but it just forces all
> enrolment comms to be kept to the named server and reorders the
> ipa_server entry in sssd.conf from "ipa_server = __srv__, x.x.x.x" to
> "ipa_server = x.x.x.x, __srv__"
> 
> Would that be enough?


That seems perfectly reasonable to me. Would you mind filing an RFE at
https://fedorahosted.org/freeipa/ please? (If you don't have a Fedora
account, you can get one for free at
https://admin.fedoraproject.org/accounts)



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Replication for sites not using FreeIPA for DNS?

[Stephen Gallagher]

On Wed, 2012-01-18 at 12:17 -0500, Ian Levesque wrote:
> Hello,
> 
> I'm running IPA version 2.1.3-9 on RHEL 6.2 and just configured
> master/master replication. From what I can tell in the documentation
> [1], all of the client-discovering-a-replica magic happens via SRV
> records in DNS. This is quite different from what I'm used to, coming
> from managing an Open Directory service in which the replicated
> server's FQDN is passed on to the client through LDAP as an additional
> LDAP/KDC server to add to the client's local config.
> 
> My question is how can I take advantage of replication if we're not
> using the FreeIPA-blessed DNS server? Do I need to manually tweak the
> SSSD config to make it aware of a second LDAP/KDC server? Is there a
> hidden flag I can pass ipa-client-install to do this for me?


In addition to Dmitri's comments (and mine in the "Forcing IPA clients
to prioritise different IPA Servers" thread) you should be aware that
just because you're not using FreeIPA as the DNS server, it doesn't mean
that you can't use SRV records to solve this problem.

The SRV records are looked up on whatever DNS server is configured
in /etc/resolv.conf. So if you ask your DNS administrator to add SRV
records for your FreeIPA replicas, you can still continue this way.

Otherwise, your best bet is to edit the sssd.conf directly (for now. As
Dmitri says, we're looking at other approaches for future FreeIPA
releases).


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers

[Stephen Gallagher]

On Wed, 2012-01-18 at 03:02 +, Charlie Derwent wrote:
> Hi
>  
> I've got 5 different IPA servers at 5 differents labs around the
> country that are all replicas of one another. In order to keep the the
> cross-site network traffic to a minimum I want the IPA clients at Site
> "A" to only communicate to IPA Server "A", "B" to "B", "C" to "C" etc.
> except in the case of the failure of one of the servers.
>  
> I originally assumed that making the IPA client to connect to a
> specific IPA server with "ipa-client-install --server=IPA_server_fqdn"
> would suffice but I very quickly found out this wasn't the case with
> the client going to multiple servers just to complete the installation
> process. Then I found out about modifying the DNS SRV records priority
> and weight however, please correct me if I'm wrong, these wouldn't
> these changes replicate and be enacted gloablly. (i.e. all clients at
> any site would prioritise IPA "A" over IPA "B").
>  
> Is there any way to get the functionality I desire?
>  

We're looking at ways to implement a concept of client location into the
connection logic. At the moment, however, the only way to do this is
manually on the client.

You can make the following change in the clients' /etc/sssd/sssd.conf
files:

In the [domain/your.domain.com] section there is an option "ipa_server".

By default, this is configured to be:
ipa_server = __srv__, x.x.x.x

(Where x.x.x.x is the server you were originally talking to when you ran
ipa-client-install, as a backup in case DNS is not working).

You can manually change this to be:
ipa_server = nearest.server.com, further.server.com,
only-in-emergencies.server.com, ...

With this manual setup, SSSD (the daemon that manages the client-side
portion) will always attempt to connect to nearest.server.com unless it
is unavailable, after which time it will fail over to the next in the
list, and so on.*


* If all of them are unavailable, SSSD switches to offline operation,
where it will try to reconnect every couple of minutes, but will serve
requests from its cache in the meantime. When it reconnects from an
offline state, it will start retrying from the first server in the list
(aka the nearest one).



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] New SSSD FAQ page in the works

[Stephen Gallagher]

On Wed, 2012-01-11 at 12:56 -0500, Dmitri Pal wrote:
> On 01/10/2012 02:31 PM, Stephen Gallagher wrote: 
> > It's come up more than once that SSSD needs a Frequently Asked Questions
> > page to field some of our more common questions. I'm reaching out to the
> > SSSD and FreeIPA user and developer communities to help us flesh out
> > this page.
> > 
> > I've begun it with the two most common questions I've received lately,
> > as well as a basic primer on enabling debug logging to help identify
> > issues.
> > 
> > I'd like some additional suggestions on what questions should be
> > answered on that page, as well as opening the page to volunteer-edits to
> > add answers to any questions they may have had and solved (or enlisted
> > aid in solving) in the past.
> > 
> > The page is available at https://fedorahosted.org/sssd/wiki/FAQ and can
> > be edited by anyone with a free Fedora account. If you don't have one,
> > you can register quickly and easily at
> > https://admin.fedorahosted.org/accounts
> > 
> > Thank you very much for your contributions.
> > 
> > Once this page has some meat, I will also be looking for interested
> > translators to take a stab at making it accessible to non-English-native
> > users.
> > 
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> 
> 1) What platforms SSSD is supported on?

Added to the FAQ

> 2) Is there an API to configure it?

I think this is more suitable for a separate porting/packaging page,
which we should probably also start writing.

> 3) What are the valid combinations of identity+password+authentication
> +authorization data providers - should be pointer to a page that
> contains a matrix  

I agree we should describe this somehow, but I'm not sure what mechanism
to use. A matrix doesn't really work because we have four providers (ID,
AUTH, ACCESS and CHPASS) that need to interact. It's hard to create a
four-dimensional matrix on a two-dimensional surface.

> 4) When should I use enumeration=true ?

Added to the FAQ


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] New SSSD FAQ page in the works

[Stephen Gallagher]

It's come up more than once that SSSD needs a Frequently Asked Questions
page to field some of our more common questions. I'm reaching out to the
SSSD and FreeIPA user and developer communities to help us flesh out
this page.

I've begun it with the two most common questions I've received lately,
as well as a basic primer on enabling debug logging to help identify
issues.

I'd like some additional suggestions on what questions should be
answered on that page, as well as opening the page to volunteer-edits to
add answers to any questions they may have had and solved (or enlisted
aid in solving) in the past.

The page is available at https://fedorahosted.org/sssd/wiki/FAQ and can
be edited by anyone with a free Fedora account. If you don't have one,
you can register quickly and easily at
https://admin.fedorahosted.org/accounts

Thank you very much for your contributions.

Once this page has some meat, I will also be looking for interested
translators to take a stab at making it accessible to non-English-native
users.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] HBAC issues

[Stephen Gallagher]

On Jan 5, 2012, at 5:48 PM, Erinn Looney-Triggs  
wrote:

> On 01/05/2012 11:54 AM, Stephen Gallagher wrote:
>> On Thu, 2012-01-05 at 11:48 -0900, Erinn Looney-Triggs wrote:
>>> Yes that look about right, not able to confirm 100%, but that is
>>> probably the issue.
>> 
>> 
>> We're looking into it. However, I should point out that using srchost is
>> a very unreliable means of restricting access. There are numerous
>> problems with it, most notably because we have to rely on what PAM sends
>> us in the srchost field, which is not defined in the spec, so different
>> applications such as 'login' and 'sshd' sometimes put different values
>> in those fields.
>> 
>> In SSSD upstream, we're defaulting to ignoring srchost rules because
>> they're 1) unreliable and 2) cause significant performance impact on
>> networks with lots of host entries.
>> 
>> Our general recommendation is that if you want to restrict access from
>> specific hosts, it's usually a better idea to do this at the firewall
>> level, rather than the HBAC level.
> 
> Well that kind of puts that whole HBAC thing on the skids doesn't it?

Well, target host works fine. The real problem is with accurately identifying 
the remote host that the connection originated from.

So you can still write rules that say "only these users can log onto these 
hosts".

> Unfortunate that it works that way, and yes firewalling is always a good
> option.
> 
> Thanks for the info,
> -Erinn
> 
> 

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] HBAC issues

[Stephen Gallagher]

On Thu, 2012-01-05 at 11:48 -0900, Erinn Looney-Triggs wrote:
> Yes that look about right, not able to confirm 100%, but that is
> probably the issue.


We're looking into it. However, I should point out that using srchost is
a very unreliable means of restricting access. There are numerous
problems with it, most notably because we have to rely on what PAM sends
us in the srchost field, which is not defined in the spec, so different
applications such as 'login' and 'sshd' sometimes put different values
in those fields.

In SSSD upstream, we're defaulting to ignoring srchost rules because
they're 1) unreliable and 2) cause significant performance impact on
networks with lots of host entries.

Our general recommendation is that if you want to restrict access from
specific hosts, it's usually a better idea to do this at the firewall
level, rather than the HBAC level.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] HBAC issues

[Stephen Gallagher]

On Thu, 2012-01-05 at 11:35 -0900, Erinn Looney-Triggs wrote:
> I am trying to solve an issue that seems like it should be obvious but
> is not, to me at least.
> 
> I am trying to allow a user to log into a single host, via GDM. I have
> configured a HBAC rule that allows access to the host from the host
> (actually to the group with the host in it from the same group).
> Unfortunately, logins are failing, what is more sssd is crashing when
> this is tried (perhaps they didn't design for a monkey like me :).
> 
> The only way that I can get logins to work is for it to be allowed from
> any host, not from the host itself. So what, if any, are the tricks here
> that I am missing?
> 
> I will send in the sssd crashing bit, abrt doesn't seem to want to list
> it even though it is is in /var/spool/abrt, so I get to monkey with it
> some other way.
> 
> This is on a RHEL 6.2 client, connected to a RHEL 6.2 server.


Any chance you might be hitting
https://bugzilla.redhat.com/show_bug.cgi?id=771706 ?


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo configuration question

[Stephen Gallagher]

On Wed, 2011-12-21 at 09:08 -0900, Erinn Looney-Triggs wrote:
> On 12/21/2011 04:37 AM, Stephen Gallagher wrote: 
> > On Tue, 2011-12-20 at 12:59 -0900, Erinn Looney-Triggs wrote:
> > > I have been working through configuring sudo via IPA and ran into the
> > > following situation.
> > > 
> > > There is a directive in the documentation to configure
> > > /etc/sssd/sssd.conf on the clients with something like the following:
> > > 
> > > ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com
> > > 
> > > 
> > > This is pulled from the docse here for reference:
> > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/example-configuring-sudo.html
> > > 
> > > This is fine and causes no problems, however, when I mistakenly left it
> > > out on a few systems, sudo continued to function, so I am wondering what
> > > it is that this directive does? Does this get sssd into the loop to
> > > cache sudo rules for offline use?
> > > 
> > > Any ideas?
> > Sorry for the confusion in the other responses to this thread. The short
> > answer is this: SUDO can use LDAP rules (as you clearly know). It does
> > this with its own internal LDAP lookup (it doesn't currently go through
> > SSSD to accomplish this).
> > 
> > However, SUDO rules can specify netgroups as part of their restrictions
> > on who can do what (usually these are used to limit functions to certain
> > hosts). In order to do this, SSSD needs to be configured to look up
> > netgroups properly so that SUDO can use the 'getnetgrent()' glibc
> > command to locate the netgroups.
> > 
> > The doc you are looking at is actually a bit out of date. It's no longer
> > necessary to provide that option, because if it's unspecified, we set it
> > automatically to cn=ng,cn=compat,dc=example,dc=com (using the
> > appropriate base, of course).
> > 
> > Jan's comments about upstream work were that we recently made changes to
> > avoid needing to use the compat tree for netgroup lookups and can
> > instead use FreeIPA's native, custom schema for netgroups. That's not
> > terribly relevant to you, but it's a useful piece of information.
> > 
> > So, in short, you don't need to set it, the doc is outdated.
> > 
> > 
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> Ok thanks, that makes sense. One final question here, is there a way
> to verify that sssd is in fact setting this properly? Not that I doubt
> you of course, it is just a matter of so many versions of sssd in so
> many places that it would be good to verify that it works
> automagically on RHEL 5, 6, and whatever else, say Ubuntu etc. 
> 
> -Erinn
> 

You can set 'debug_level = 6' in [domain/] of sssd.conf and
restart. If you look in the sssd_.log, you should see a line
setting the ldap_netgroup_search_base option.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo configuration question

[Stephen Gallagher]

On Tue, 2011-12-20 at 12:59 -0900, Erinn Looney-Triggs wrote:
> I have been working through configuring sudo via IPA and ran into the
> following situation.
> 
> There is a directive in the documentation to configure
> /etc/sssd/sssd.conf on the clients with something like the following:
> 
> ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com
> 
> 
> This is pulled from the docse here for reference:
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/example-configuring-sudo.html
> 
> This is fine and causes no problems, however, when I mistakenly left it
> out on a few systems, sudo continued to function, so I am wondering what
> it is that this directive does? Does this get sssd into the loop to
> cache sudo rules for offline use?
> 
> Any ideas?

Sorry for the confusion in the other responses to this thread. The short
answer is this: SUDO can use LDAP rules (as you clearly know). It does
this with its own internal LDAP lookup (it doesn't currently go through
SSSD to accomplish this).

However, SUDO rules can specify netgroups as part of their restrictions
on who can do what (usually these are used to limit functions to certain
hosts). In order to do this, SSSD needs to be configured to look up
netgroups properly so that SUDO can use the 'getnetgrent()' glibc
command to locate the netgroups.

The doc you are looking at is actually a bit out of date. It's no longer
necessary to provide that option, because if it's unspecified, we set it
automatically to cn=ng,cn=compat,dc=example,dc=com (using the
appropriate base, of course).

Jan's comments about upstream work were that we recently made changes to
avoid needing to use the compat tree for netgroup lookups and can
instead use FreeIPA's native, custom schema for netgroups. That's not
terribly relevant to you, but it's a useful piece of information.

So, in short, you don't need to set it, the doc is outdated.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind

[Stephen Gallagher]

On Fri, 2011-12-02 at 15:59 +0100, Ondrej Valousek wrote:
> Small update so I am not only throwing dirt on winbind:
> 
> Winbind has still its use if you can not use / do not have RFC2307
> attributes in AD. 
> So simply, if you want to use RFC2307 attributes, sssd is here for
> you. If not, go for winbind. But yet I would not bother about winbind
> plugin for sssd as it does not make too much sense - that's why we
> have Glibc and its /etc/nsswitch.conf!

Well, just to make one point, there are a few advantages to the winbind
backend over pure winbind:

1) SSSD caching instead of nscd
2) Support for multiple AD domains without trust
3) One-to-one mapping of identity domain to authentication domain (so
you're not exposing your password to multiple authentication domains
until you find the right one, as with traditional PAM).


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind

[Stephen Gallagher]

When we originally designed SSSD, we looked at it as a solution for
dealing with LDAP and Kerberos identity and authentication for Linux and
UNIX clients. With our initial approach, we decided to include only
marginal support for Microsoft's Active Directory as a source of user
information (only supporting it when it is enabled for use with
posixAccount and posixGroup object classes).

Our original assumption was that for complicated deployments relying on
Active Directory, users would prefer to continue using Winbind. It has a
very long history and is specifically designed around managing the
peculiarities of Microsoft's LDAP implementation.

Of late, it has become apparent that many users are opting to "jump
ship" from winbind to SSSD for use with Active Directory. This has been
shown by a sharp uptick in community bug reports with Active Directory
servers.

Up until now, our plans around Active Directory have circulated around
including a "Winbind Provider" into SSSD, similar to the LDAP provider
but making use of the original winbind features found in the Samba
project. However, it's beginning to seem like users are expressing an
interest to move AWAY from that solution.

This may result in a change in our strategy going forward. I'm looking
for users to describe to us the reasons why they're choosing SSSD (in
its current incarnation) over winbind. What I'm trying to sort out is
whether there are specific *issues* with winbind that SSSD is solving
for users. In other words, I'm trying to determine whether our decision
to write and support a winbind provider backend is misplaced.

It may be that if SSSD's LDAP provider is offering a significant
advantage over winbind, we will consider dropping (or deferring) our
efforts to integrate winbind and instead put that effort into adding
Active Directory-specific features into the LDAP provider. For example,
we might reprioritize bugs https://fedorahosted.org/sssd/ticket/995 and
https://fedorahosted.org/sssd/ticket/996

So please, share with us your stories for why you prefer SSSD over
winbind and help us choose our direction for SSSD's future.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Limiting group/user visibility

[Stephen Gallagher]

On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote:
> On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi Pölönen wrote:
> > Hi,
> > 
> > I'm looking for implementing FreeIPA in an environment where there are
> > multiple customers in multiple organizations and a single organization
> > that manages the users, sets the access rights etc.
> > 
> > We don't have a centralized system currently so I will be starting from
> > the scratch in that sense. The first concern I've had so far is that we
> > don't want different customers to be able to find information about each
> > other. Currently in my test setup any user can find out every user in a
> > group if they know the group name and all the groups for each user if
> > they know the username. In some cases this might reveal information the
> > customer is not willing to share.
> > 
> > So are there ways to limit that e.g certain hosts/hostgroups or
> > users/usergroups see some defined subset of the directory? Or are there
> > some other suggested approaches? As the current setup relies on local
> > authentication, users naturally are able to find users/groups only on
> > servers they are able to log in and that is the level of confidentiality
> > we are looking for if possible
> > 
> > 
> > -Lassi Pölönen
> > 
> > 
> 
> If you insist on a single instance for multiple organizations, then I
> agree with Stephen Ingram that the correct way would be to setup ACIs.
> 
> You could also abuse the ldap_user_search_filter and ldap_group_search_filter
> parameters to limit NSS lookups performed by SSSD. However, nothing
> would prevent clients from looking at the directory structure with
> ldapsearch or using the IPA UI.

Please note that the *search_filter options aren't fully functional yet.
We're improving them substantially for the 1.7.0 release of SSSD.

But Jakub is right: if you manipulate the ACIs of your user entries,
then you can restrict which client machines can see those entries.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Automount kerberos errors

[Stephen Gallagher]

On Tue, 2011-11-22 at 15:01 -0500, Dmitri Pal wrote:
> On 11/22/2011 02:46 PM, Sigbjorn Lie wrote:
...
> > I get the following error messages in the log, once a day. It seem
> > like the ticket expires before it's renewed. Has anyone else seen
> > this? Or perhaps I should file a bug report on the automounter? I
> > don't get this error message on Red Hat 6 clients.
> >
> > I also get the error where automount says sss is not a supported
> > automount source, even though the ipa-client-install script configured
> > nsswitch to look up automount in sss. I get this error message on both
> > Red Hat 5 and Red Hat 6 machines. What's going on?
> >
> >
> >
> >
> > Nov 20 15:49:15 redhat5 automount[26234]: ignored unsupported autofs
> > nsswitch source "sss"
> 
> 
> SSSD does not support automount integration yet.

We are working on adding support for automount in SSSD. See the
following bug for details:
https://bugzilla.redhat.com/show_bug.cgi?id=683523


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP authentication into FreeIPA

[Stephen Gallagher]

On Tue, 2011-11-15 at 16:51 -0500, Boris Epstein wrote:
> > 
> > 
> > 
> > 
> > Just tried to install sssd from the above repo.
> > 
> > There's only packages for the old 10.04 lucid and
> > 10.10 maverick, nothing for 11.04 natty or 11.11
> > oneiric. I tried to install on natty using packages
> > from maverick, but it depends on packages no longer
> > available in the natty package tree. :(
> > 
> > However for oneric sssd 1.5.13 seem to have made it
> > into the universe package tree:
> > http://packages.ubuntu.com/oneiric/sssd
> > 
> > 
> > 
> > Rgds,
> > Siggi
> > 
> > 
> > Siggi,
> > 
> > 
> > Thanks, but why would I want sssd on my client machine?
> > 
> > 
> > Or - why would the current LDAP client that Ubuntu at least
> > claims to have not work?
> > 
> > 
> 
> 
> The reasons I've found so far is:
> 
> * Lack of support for the host based access control rules
> found in IPA
> * Need to have the config file with a username/password for
> the system to bind to the ldap directory readable by
> everyone... (not secure)
> * SSSD uses the kerberos host key to talk to LDAP (secure)
> * No daemon keeping track of available ldap servers, e.g. in a
> failover situation you'll keep asking the server that's down,
> delaying your client response.
> * No offline caching of credentials (very handy if you have
> laptops).
> 
> I'm sure the SSSD developers can give you lots more. :)


I think you've hit most of the major points. The less-obvious one is
that at it reduces load on the LDAP server as well, since all
communications come from a single connection in the SSSD, whereas with
traditional nss_ldap, each client application would be holding its own
connection.


> 
> Siggi,
> 
> 
> Thanks, all of those are valid. I just installed sssd on an Ubuntu
> machine here, may end up using it.
> 
> 
> But from what you are saying it still sounds like the existing LDAP
> client on Ubuntu ought to still work, even if in a less than secure
> fashion. And it doesn't seem to.

I've seen people successfully configure pam_ldap and pam_krb5 on Ubuntu
before, so I know it's possible. I assume you have a configuration bug.
I don't know where Ubuntu keeps its config, so I can't easily help you
there.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP authentication into FreeIPA

[Stephen Gallagher]

On Tue, 2011-11-15 at 20:40 +, Steven Jones wrote:
> Hi,
> 
> I dont think there is much realistic hope of getting windows to
> authenticate to freeIPA..the others should be able to and the
> fedora docs on the freeipa documentation web page list a specific
> method for macs for one (but I have not tried it yet, but I will
> be)ubuntu has been mentioned beforeI have to try/do that as
> well
> 
> Siggi sent me some notes a while back,
> 
> =
> 
> Ubuntu client install


I don't have all of the details handy right now, but I know Timo
Aaltonen was working on porting SSSD and ipa-client to Ubuntu in order
to support the enhanced client enrollment available with those two
packages.

The SSSD and its dependencies are available in his PPA here:
https://launchpad.net/~tjaalton/+archive/ppa


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] sssd not updating reverse dns

[Stephen Gallagher]

On Sun, 2011-11-13 at 19:19 +0100, Sigbjorn Lie wrote:
> On 11/13/2011 02:48 PM, Simo Sorce wrote:
> > On Sat, 2011-11-12 at 15:55 +0100, Sigbjorn Lie wrote:
> >> Hi,
> >>
> >> I notice that when sssd is configured to update DNS, it's only updating
> >> the DNS forward zone, it's not updating the DNS reverse zone. And I
> >> cannot find any option for enabling updating of the reverse dns zone.
> >>
> >> Have I missed something? Or is updating the reverse zone not supported?
> > It is not supported at this time.
> > While we have a way to determine if your host has any right to update
> > the machine A/ name because we can check if the host authenticated
> > using a key of type host/@REALM we have no way to validate that
> > a host has any right to update a PTR record.
> >
> > Allowing a host to change any PTR record in any reverse zone would be
> > very disruptive as a compromised host could change PTR records for
> > important servers.
> >
> Ok, I see the issue.
> 
> I notice ISC dhcpd adds a TXT record along with the updated record with 
> a string that identifies that host record being "owned" by that dhcpd. 
> And it does not attempt to update DNS if it cannot validate the content 
> of the TXT record, or there already exists a record without a 
> corresponding TXT record.
> 
> Perhaps a similar approach could be applied to IPA? Using attributes in 
> the LDAP DNS tree instead of TXT records.. ?
> 

SSSD doesn't user LDAP in any way while updating the DNS records. We
actually just use GSS-TSIG to speak directly to the DNS server. We
suggested using XML-RPC communication to the FreeIPA server at one
point, but we decided that it was probably for the best to just stick
with the standardized approach for now.

The flip side of this is, of course, that we cannot update the PTR
records (due to the security risks that Simo pointed out). So maybe we
should consider putting this back on the table.

> > We are trying to make sure (patches, configurations) that reverse
> > resolution is disabled for kerberos and canonicalization does not use it
> > by default as it is unreliable in any case.
> Yes, I've noticed. :) Authentication based on forward/reverse lookups 
> aside, being able to look up reverse IP records does help 
> troubleshooting. And it becomes almost a requirement for being able to 
> manage IPv6 networks.
> 
> It would be very nice to see reverse address update implemented in SSSD 
> at some point. Is there already an open RFE?

There is no RFE for this yet. Please feel free to open one at
https://fedorahosted.org/sssd




signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Fedora 16 installer

[Stephen Gallagher]

On Thu, 2011-11-10 at 23:08 +0100, Sigbjorn Lie wrote:
> Hi,
> 
> I just installed Fedora 16 and noticed that there now was an option for 
> using FreeIPA as autentication database. Awesome!
> 
> But why the normal ldap/kerberos options that met me when I chose 
> FreeIPA (see the attachment). I was picturing auto-detection, and just a 
> username and password, same as the simplified CLI installer.
> 
> Is this on the roadmap for the Fedora/RHEL installer?
> 
> And, what about IPA options for the "auth" kickstart directive?
> 

That has actually been there since Fedora 14, and it's meant for use
with FreeIPA v1, not v2. We do need to do something about that for F17,
though.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] FreeIPA on CentOS 5.6

[Stephen Gallagher]

On Wed, 2011-11-09 at 14:23 -0500, Boris Epstein wrote:
> 
> So what OS would not be too old to run FreeIPA on? Would we be talking CentOS 
> 6?
> 
> Boris.

Well, RHEL 6.2 (due out before the end of the year) will include a
fully-supported version of FreeIPA as "Red Hat Identity Management".
Presumably, whenever CentOS 6.2 is released, it will also carry this
package.

It's likely to be possible to get it to run on CentOS 6.0, but it will
require some elbow grease. I also agree with the earlier comments that
512MB is not enough to run the OS + FreeIPA.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] FreeIPA on CentOS 5.6

[Stephen Gallagher]

On Wed, 2011-11-09 at 13:46 -0500, Boris Epstein wrote:
> On Wed, Nov 9, 2011 at 1:39 PM, Stephen Gallagher  wrote:
> > On Wed, 2011-11-09 at 12:50 -0500, Boris Epstein wrote:
> >> Hello all,
> >>
> >> I am an absolute beginner here... So... I have a machine that only has
> >> 512 MB of RAM which is too small to house Fedora. So that machine is
> >> running CentOS 5.6. And now I want to install FreeIPA on it. Has
> >> anybody done it? If so, how have you done it?
> >
> >
> > FreeIPA is not supported on RHEL/CentOS 5.x. It's simply too old and
> > cannot meet the minimum pre-requisites.
> >
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> >
> 
> Too old? How?
> 
> http://freeipa.org/page/IPAv2_213
> 
> This was released in October 2011. So yes, it is over a week old:)
> 
> But I doubt that makes it ancient:)
> 
> Boris.

Sorry, that will teach me to leave my pronouns ambiguous.

I mean that RHEL/CentOS 5 is too old to be capable of running FreeIPA.
There are too many dependencies of FreeIPA that are unmet.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] FreeIPA on CentOS 5.6

[Stephen Gallagher]

On Wed, 2011-11-09 at 12:50 -0500, Boris Epstein wrote:
> Hello all,
> 
> I am an absolute beginner here... So... I have a machine that only has
> 512 MB of RAM which is too small to house Fedora. So that machine is
> running CentOS 5.6. And now I want to install FreeIPA on it. Has
> anybody done it? If so, how have you done it?


FreeIPA is not supported on RHEL/CentOS 5.x. It's simply too old and
cannot meet the minimum pre-requisites.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP search for email address of user in a particular group

[Stephen Gallagher]

On Fri, 2011-11-04 at 17:12 -0400, Dan Scott wrote:
> Hi,
> 
> I've just migrated a couple of servers from FreeIPA 1.2 to 2.1. I'm
> almost done. I just have a few custom LDAP searches to migrate.
> 
> With the old system, I was trying to look users who are in a
> particular group by their email address i.e.
> 
> ldapsearch -b cn=users,cn=accounts,dc=example,dc=com
> "(&(mail=${email_address})(memberOf=cn=usergroup,cn=groups,dc=example,dc=com"
> -x
> 
> In version 2, it looks like the memberOf attributes have been removed
> from the user entries and the user group membership information is
> stored only in the 'member' attribute of the individual group entries.


memberOf exists, but you have to be connecting to LDAP with an
authenticated user who has privilege to see the memberOf attribute. I
believe (Rob can correct me) this means either an administrator or a
host principal.

So if you try doing (from an enrolled client):

kinit -k -t /etc/krb5.keytab host/@IPAREALM
ldapsearch -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=com
"(&(mail={email_address})(memberOf=cn=usergroup,cn=groups,dc=example,dc=com"

You should get results.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Complaint web browsers

[Stephen Gallagher]

On Tue, 2011-10-18 at 16:52 +0100, duncan.in...@virginmoney.com wrote:
> Just as a pointer here - It would be good if there was ubiquitous
> support amongst the browsers.  I understand the whole concept behind
> "we test what we ship with", but we're no longer talking about huge
> differences between browsers these days.  Would it be possible to look

Unfortunately, this is not true for the internals of the browsers. In
general, they're all pretty standardized these days on how a page should
look but they vary wildly in how they manage some features, like
authentication in any way other than HTTP-BASIC.

Specifically, they all support Kerberos to varying degrees. Each browser
requires a completely different mechanism for configuring the use of
Kerberos so that it can be passed to the web server. The one that is
both most complete in its support and most simplistic to configure is
Firefox, which is why it is the only officially supported browser at
this time.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Question on AD to freeipa sync

[Stephen Gallagher]

These are all great ideas, Ondrej. Would you mind opening RFE bugs for
them? You can file them upstream at https://fedorahosted.org/sssd or in
Red Hat Bugzilla https://bugzilla.redhat.com in the sssd component.

On Tue, 2011-10-04 at 16:29 +0200, Ondrej Valousek wrote:
> 
> > Can you provide more information here? We DO have support for automatic
> > detection based on DNS SRV records. Does a "DC locator" use some other
> > mechanism?
> > 
> Example AD domain CONTOSO.COM used on 3 sites - Prague,Cork, Dublin.
> I have machine in Prague and I want it to join CONTOSO.COM. Now if I
> used:
> 
> dns_discovery_domain = contoso.com
> 
> sssd would try to connect to any DC in the domain - even the one in
> Dublin, completely ignoring sites.
> I have to use:
> 
> dns_discovery_domain = Prague._sites.contoso.com
> 
> To force it to use Prague DCs only.
> My understanding is, that the "DC locator" tries to communicate with
> DC's first to determine local site and remote DC's are only used if no
> valid/working DC can be found in the local site (Prague in this case).
> 
> > I'm not sure what you mean by this? Do you mean you don't want to have
> > to specify ldap_schema = rfc2307bis and have it instead auto-detected?
> > 
> > That's trickier than it sounds.
> > 
> well this is a really small one. I would say it would be perfectly
> sufficient to introduce something like:
> 
> ldap_schema=msrfc2307bis 
> 
> which would be equivalent to:
> 
> ldap_user_object_class = user
> ldap_group_object_class = group
> ldap_user_home_directory = unixHomeDirectory
> ldap_schema = rfc2307bis
> 
> also, the ldap bind mechanism negotiation could be potentially
> improved, now I have to explicitly specify
> 
> ldap_sasl_mech = GSSAPI
> 
> otherwise sssd tries to use SASL/EXTERNAL which fails when
> communicating to AD controllers.
> 
> > What features of the krb5 library do you mean? SSSD provides a locator
> > plugin that manages several features of the krb5 library, including
> > kinit and kpasswd.
> > 
> The thing is that not all Linux apps are using sssd so we have to
> remember to configure /etc/krb5.conf. too.
> When using Centrify, all I need to do is:
> 
> # adjoin contoso.com
> 
> ..which takes care of everything - /etc/nsswitch.conf, krb5.conf, PAM
> modules, eeeverything. If I wanted to use sssd for the same job I have
> to:
> 
> 1. configure (manually) /etc/samba/smb.conf
> 2. net ads join (- just to get machine creds)
> 3. configure (manually) sssd.conf
> 4. configure (manually) PAM modules
> 5. configure (manually) krb5.conf
> 
> I understand that much of this is probably not sssd duty, but it would
> be helpful to have some script around which would do the same job.
> 
> 
> __
> The information contained in this e-mail and in any attachments is
> confidential and is designated solely for the attention of the
> intended recipient(s). If you are not an intended recipient, you must
> not use, disclose, copy, distribute or retain this e-mail or any part
> thereof. If you have received this e-mail in error, please notify the
> sender by return e-mail and delete all copies of this e-mail from your
> computer system(s). Please direct any additional queries to:
> communicati...@s3group.com. Thank You. Silicon and Software Systems
> Limited (S3 Group). Registered in Ireland no. 378073. Registered
> Office: South County Business Park, Leopardstown, Dublin 18 
> 
> __
> 
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users




signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Question on AD to freeipa sync

[Stephen Gallagher]

On Tue, 2011-10-04 at 14:53 +0200, Ondrej Valousek wrote:
> Well, small things like sssd can not renew machine credentials /

As Jan said, this is being looked into.

>  sssd can not detect local site automatically in AD domain (no "DC
> locator" implemented) /

Can you provide more information here? We DO have support for automatic
detection based on DNS SRV records. Does a "DC locator" use some other
mechanism?

> sssd can not detect/guess AD schema automatically

I'm not sure what you mean by this? Do you mean you don't want to have
to specify ldap_schema = rfc2307bis and have it instead auto-detected?

That's trickier than it sounds.

> / sssd won't configure the krb5 library for me.

What features of the krb5 library do you mean? SSSD provides a locator
plugin that manages several features of the krb5 library, including
kinit and kpasswd.

> Support for group policies & central management & auditing (Centrify
> nicely fills the OperatingSystem attribute for me) would be also nice.
> 

These are on our long-term roadmap.

> Most of this is understandable as much of these requests are either
> AD-specific (hard to blame sssd here) or a RFE is already opened for
> such a functionality.
> 
> Anyway, it is still a way better than the classic libnss_ldap.so. :-) 

That is certainly our goal :)


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Question on AD to freeipa sync

[Stephen Gallagher]

On Tue, 2011-10-04 at 09:32 +0200, Ondrej Valousek wrote:
> I have ~50 servers and yes, we are using Centrify now - and yes, it is
> pain in the ass (need to take care of the licenses).
> But I have found out recently that sssd can do much of the Centrify's
> duty (authorization & authentication) - well, it is not so polished,
> but it seems to work well.

As the lead SSSD developer, I can't help but chime in here and ask what
polish you'd like to see :)

RFEs and bugs can be filed upstream at https://fedorahosted.org/sssd
(Requires a Fedora account, you can get one at
https://admin.fedoraproject.org/accounts) 


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Question on AD to freeipa sync

[Stephen Gallagher]

On Mon, 2011-10-03 at 10:03 +0200, Ondrej Valousek wrote:
> Just wondering why would anyone want to sync freeIPA and AD - both can
> serve Linux systems fine, so if I already have AD, I no longer require
> IPA.
> My 2 cents...


AD can serve Linux systems with a very limited definition of "fine". All
support in Active Directory for POSIX compliance is an afterthought to
Microsoft. It exists solely to try and migrate customers from UNIX to
Windows, and really isn't designed for the purpose.

One of the major problems with using AD for Linux support is that it
violates the LDAP and Kerberos standards in several key places, meaning
that the experience on Linux is significantly degraded from that of
Windows machines. For example, in order to support very large group
memberships (>1000 members), Active Directory requires the use of a
special LDAP control to retrieve the members list a page at a time in
several LDAP communications. The way it does this is expressly violating
the LDAP protocol standard, which means that without rewriting all
clients on Linux to break the standard in the same way, Linux and UNIX
machines are capable of only seeing the first thousand members of a
group.

Another problem with Active Directory is its limited support for LDAP
authentication. AD expects that all of its clients are Windows machines,
and therefore capable of using Kerberos and/or NTLM for all
authentication. However, some applications (especially Linux-powered web
applications) can only authenticate using LDAP simple bind
authentication. While AD does have some support for this, LDAP auth
breaks completely in the case of expired users (it has no support for a
password-change grace period with LDAP authentication).

Yet further, in many environments, there are two very different
organizations in the IT departments: one group that manages Windows
systems and one that manages Linux/UNIX systems. By having FreeIPA be
capable of acting as a bridge between the two (either by the current
mechanism of user-syncing or by the forthcoming FreeIPA v3 mechanism of
Kerberos trusted realms), it allows IT departments to continue to hire
staff that knows one system well. It's very hard to find people with a
deep knowledge of both systems; people tend to specialize. It's much
better to let your Linux admins work on the Linux machines, rather than
trying to force your MCSEs to learn the intricacies of a LAMP setup.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Cannot login to GDM

[Stephen Gallagher]

On Fri, 2011-09-23 at 13:38 -0400, Dan Scott wrote:
> Hi,
> 
> I've recently upgraded from FreeIPA 1.2 to 2.1. Most things are
> working OK, but I have a few problems:
> 
> 1. I'm unable to login to a new client machine via GDM with my
> existing credentials. i.e. I can login on the command line and my home
> directory is created correctly, but GDM logins hang, with the fields
> greyed out until I press escape, when it returns to the login screen.
> The /var/log/gdm files contain:
> 
> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message
> with a timestamp of 0 for 0x147 (Login Wind)
> Window manager warning: meta_window_activate called by a pager with a
> 0 timestamp; the pager needs to be fixed.
> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message
> with a timestamp of 0 for 0x147 (Login Wind)
> Window manager warning: meta_window_activate called by a pager with a
> 0 timestamp; the pager needs to be fixed.
> 
> ==> /var/log/gdm/:0-slave.log <==
> pam: gdm-password[2484]: pam_unix(gdm-password:auth): authentication
> failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=  user=djscott
> pam: gdm-password[2484]: pam_sss(gdm-password:auth): authentication
> success; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=djscott
> 
> ==> /var/log/gdm/:0-greeter.log <==
> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message
> with a timestamp of 0 for 0x147 (Login Wind)
> Window manager warning: meta_window_activate called by a pager with a
> 0 timestamp; the pager needs to be fixed.
> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message
> with a timestamp of 0 for 0x147 (Login Wind)
> Window manager warning: meta_window_activate called by a pager with a
> 0 timestamp; the pager needs to be fixed.
> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message
> with a timestamp of 0 for 0x147 (Login Wind)
> Window manager warning: meta_window_activate called by a pager with a
> 0 timestamp; the pager needs to be fixed.
> 
> Any idea what's going on here?

Could you check /var/log/secure?

Also, what version of the sssd and gdm packages are installed on the
system?

> 
> 2. I'm having trouble migrating the user passwords. The
> /ipa/migration/ webpage doesn't work:
> 
> "There was a problem with your request. Please, try again later."
> 
> The only way I have been able to migrate user passwords is by getting
> them to ssh into one of the FreeIPA masters. I've read through
> manpages for sssd, sssd.conf, sssd-ldap, sssd-krb5 and pam_sss, and
> the FreeIPA and SSSD websites, but I can't find the documentation for
> getting SSSD to migrate passwords. Can someone point me in the correct
> direction?
> 

There's no special configuration required for getting SSSD to migrate
passwords. As long as password migration mode is configured on the
FreeIPA server (and SSSD has been set up with ipa-client-install), we
will detect whether migration mode is active and behave appropriately.
This is exactly why migration by connecting to the FreeIPA masters by
SSH works; it's authenticating through the SSSD client on the master and
performing the migration quietly behind the scenes.

If this isn't working when SSHing into FreeIPA clients other than the
server, then there's probably something wrong with your SSHD config.

Otherwise, whatever's causing the failure in step 1) is probably causing
the migration to not work (since authentication isn't completing).

> 3. The migration appears to have created a group for each user, i.e.
> there is a group called 'djscott' along with my user, visible via an
> LDAP browser. Should they exist? Is there an easy way to remove them -
> they don't show up in the web interface or command line, just the LDAP
> browser.

These are private groups and they are a security feature. The idea is
that each user is by default a member only of a special group consisting
only of themselves. This way, when a user creates a file with default
permissions, it isn't vulnerable to leaking to other members of the
user's primary group.

> 4. The old ipausers group had ID 1002, which now does not exist,
> resulting in an annoying "id: cannot find name for group ID 1002"
> whenever I ssh to another system. Is there a simple way to change the
> GID for all users who have the old ID to have the new ID? I've created
> a temporary ipausers-legacy group with ID 1002 to eliminate the error
> temporarily.

I'll leave this for the core FreeIPA team to discuss, but the removal of
ipausers was intentional, in favor of using private groups as I
described above.

> 
> I think that's it for now :)
> 
> Thanks,
> 
> Dan Scott
> http://danieljamesscott.org/
> 
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users




signature.asc
Description: This is a digitally signed message part
__

Re: [Freeipa-users] password migration

[Stephen Gallagher]

On Tue, 2011-09-20 at 09:59 -0400, Dmitri Pal wrote:
> 3) After importing users use SSSD in migration mode (special setting in
> SSSD config). In this case for any user without kerberos hash who would
> log via SSSD the SSSD would connect IPA in a special way and trigger the
> Kerberos hash generation. 

Migration mode in SSSD is not a client-side configuration. We ask the
FreeIPA server whether migration is active.

Specifically, the way SSSD behaves is as follows:
1) Try to authenticate with Kerberos. If Kerberos responds that there's
no hash for this user,
2) Ask FreeIPA if migration mode is enabled, if it is,
3) Try to bind to FreeIPA LDAP using the same password. If this
succeeds, we know that the password is valid
4) Initiate a kerberos password-change to set the kerberos password
equal to the LDAP password.


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Debian clients?

[Stephen Gallagher]

On Fri, 2011-09-16 at 14:01 -0400, Simo Sorce wrote:
> There is some work being done to make ipa-client -install more cross
> platforms, and we also have some contrib scripts, but we do not have a
> complete ipa-client-install script for debian based distributions yet.
> So you'll have to manually (or script) configure all components for now.


I've opened https://fedorahosted.org/freeipa/ticket/1809 (Document
manual steps to configure SSSD as an IPA client).


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Error message when denied by HBAC

[Stephen Gallagher]

On Tue, 2011-09-06 at 20:58 +0200, Sigbjorn Lie wrote:
> On 09/06/2011 08:37 PM, Stephen Gallagher wrote:
> > On Tue, 2011-09-06 at 20:04 +0200, Sigbjorn Lie wrote:
> >> Hi,
> >>
> >> I attempt a login with a user account that's being denied access to the
> >> host via HBAC, I receive the following generic error message.
> >>
> >> Sep  6 20:02:03 ipa01 sshd[11592]: pam_sss(sshd:account): Access denied
> >> for user username: 4 (System error)
> >>
> >>
> >> Would it be an idea to change this to advise that the user login was
> >> denied due to HBAC rules? I see this is a bit confusing.
> >
> > "System error" means that something went wrong with processing. It
> > defaults to DENY (to be safe), but it's actually an error.
> >
> > What version of SSSD are you running on the client? We fixed a fair
> > number of HBAC bugs in the 1.5.13 release (which is currently in the
> > updates-testing repos for F14, F15 and F16).
> 
> sssd-1.5.12-1.fc15.x86_64
> sssd-client-1.5.12-1.fc15.x86_64
> 
> I see there's some problems. :)
> 
> I cannot log in if no exactly the user is mentioned and exactly the host 
> mentioned in the rule. If I attempt to use user groups and host groups 
> in a hbac rule, I receive the error above. Was there a related bug fixed 
> in 1.5.13?

https://fedorahosted.org/sssd/wiki/Releases/Notes-1.5.13

Yes, there were three HBAC bugs fixed. User groups and host groups now
work properly. (The other bug was related to groups with no mumbers).

Please try sssd-1.5.13-1.fc15.2 from updates-testing (actually, it looks
like it hasn't hit the mirrors yet, so wait a day or so).


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Error message when denied by HBAC

[Stephen Gallagher]

On Tue, 2011-09-06 at 20:04 +0200, Sigbjorn Lie wrote:
> Hi,
> 
> I attempt a login with a user account that's being denied access to the 
> host via HBAC, I receive the following generic error message.
> 
> Sep  6 20:02:03 ipa01 sshd[11592]: pam_sss(sshd:account): Access denied 
> for user username: 4 (System error)
> 
> 
> Would it be an idea to change this to advise that the user login was 
> denied due to HBAC rules? I see this is a bit confusing.


"System error" means that something went wrong with processing. It
defaults to DENY (to be safe), but it's actually an error.

What version of SSSD are you running on the client? We fixed a fair
number of HBAC bugs in the 1.5.13 release (which is currently in the
updates-testing repos for F14, F15 and F16).


signature.asc
Description: This is a digitally signed message part
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users