from:"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] freeipa and gdm

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] freeipa and gdm

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

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

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] Transfer user database to FreeIPA LDAP

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] odd cron behaviour

2012-06-15 Thread 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?

2012-06-11 Thread 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

2012-06-06 Thread 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

2012-06-04 Thread 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

2012-05-22 Thread 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

2012-05-11 Thread 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?

2012-05-09 Thread 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.

2012-05-01 Thread 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] freeIPA bug: Kerberos clients fails taking to IPA server after ipa-client-install

2012-05-01 Thread 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.

2012-05-01 Thread 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] Unable to login to some clients if one of the IPA servers is down.

2012-04-30 Thread 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] Password migrating into IPA with SSSD failed

2012-04-30 Thread 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 username' 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] Problem: How to download the keytab from IPA without resetting/regenerating a new one??

2012-04-27 Thread 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

2012-03-08 Thread 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] IPA hostnames. Why not use `hostname -fqdn` instead of forcing `hostname` to be fully qualified?

2012-03-02 Thread 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] SSSD (sssd_be) crashing on RHEL 6.2

2012-03-02 Thread 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] SSSD (sssd_be) crashing on RHEL 6.2

2012-03-02 Thread 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] IPA, samba, and secondary groups

2012-02-29 Thread 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] IPA, samba, and secondary groups

2012-02-29 Thread Stephen Gallagher

On Wed, 2012-02-29 at 13:49 -0500, Kelvin Edmison wrote:
 
 
 On 12-02-29 1:40 PM, Stephen Gallagher sgall...@redhat.com 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] devel repo

2012-02-28 Thread 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?

2012-02-10 Thread 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 d...@redhat.com 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] FreeIPA 2.2 alpha or beta available somewhere?

2012-02-10 Thread 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] Other distro clients

2012-02-02 Thread 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] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD

2012-02-01 Thread 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

2012-01-31 Thread 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

2012-01-31 Thread 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

2012-01-31 Thread 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*
 https://bugzilla.redhat.com/show_bug.cgi?id=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

2012-01-30 Thread 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] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD

2012-01-30 Thread 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] ipa migrate-ds failing when more than 1 namingcontext is available

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] Fedora 16 client not getting group names

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 groupname

where groupname 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] Fedora 16 client not getting group names

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 sgall...@redhat.com 
  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 groupname
  
   where groupname 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] ipa migrate-ds failing when more than 1 namingcontext is available

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] Using DHCPD with IPA

2012-01-25 Thread 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

2012-01-20 Thread 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

2012-01-19 Thread 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] Forcing IPA clients to prioritise different IPA Servers

2012-01-19 Thread 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] New SSSD FAQ page in the works

2012-01-11 Thread 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

2012-01-10 Thread 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

2012-01-05 Thread 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] HBAC issues

2012-01-05 Thread Stephen Gallagher



On Jan 5, 2012, at 5:48 PM, Erinn Looney-Triggs erinn.looneytri...@gmail.com 
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] Sudo configuration question

2011-12-21 Thread 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] Sudo configuration question

2011-12-21 Thread 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

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).

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/DOMAINNAME] of sssd.conf and
restart. If you look in the sssd_DOMAINNAME.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

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

2011-12-02 Thread 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] IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind

2011-12-02 Thread 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

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

2011-12-01 Thread 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] LDAP authentication into FreeIPA

2011-11-16 Thread 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] sssd not updating reverse dns

2011-11-14 Thread 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/A-name@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

2011-11-11 Thread 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

2011-11-09 Thread 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] FreeIPA on CentOS 5.6

2011-11-09 Thread 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 sgall...@redhat.com 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] LDAP search for email address of user in a particular group

2011-11-07 Thread 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/fqdn@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

2011-10-18 Thread 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

2011-10-04 Thread 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

2011-10-04 Thread 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

2011-10-03 Thread 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

2011-09-23 Thread 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
___
Freeipa-users mailing list
Freeipa-users@redhat.com

Re: [Freeipa-users] password migration

2011-09-20 Thread 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?

2011-09-16 Thread 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

2011-09-06 Thread 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] Use of FreeIPA or FreeIPA LDAP server to hold private keys

2011-08-03 Thread Stephen Gallagher

On Wed, 2011-08-03 at 10:14 -0400, Ian Stokes-Rees wrote:
 
 
 On 8/3/11 4:47 AM, Ondrej Valousek wrote: 
  Maybe stupid question, but I have to ask:
  Why would anyone want to store user RSA keys in LDAP? Once you have
  IPA server with KDC installed, you can use Kerberos for
  authentication as well.
  And you get single sign on as a special bonus :-)
 
 If you only work in a single administrative domain, this is fine.  I
 am constantly accessing systems all over the US, and internationally,
 and the use of ssh-key-based authentication allows me to do this
 without continuous password prompts.  In fact, on many of the systems
 I can *only* access them by ssh-key.  Being able to hold those keys in
 central keystore like FreeIPA with a single passphrase, and the
 ability for an administrator to reset that passphrase, is very
 desirable for me and for the other users of the systems I'm a part of.
 Resetting key-based access control if the private key passphrase is
 lost is always a nuisance.


As a general rule, I would think that having your private key stored
somewhere that an admin other than yourself can reset the password and
have access to would be really dangerous. Most especially if this
private key was being used to access sites in other administrative
domains.

That really sounds like an accident waiting to happen...


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] Use of FreeIPA or FreeIPA LDAP server to hold private keys

2011-08-03 Thread Stephen Gallagher

On Wed, 2011-08-03 at 12:21 -0400, Ian Stokes-Rees wrote:
 
 On Wed Aug  3 10:37:45 2011, Stephen Gallagher wrote:
  As a general rule, I would think that having your private key stored
  somewhere that an admin other than yourself can reset the password and
  have access to would be really dangerous. Most especially if this
  private key was being used to access sites in other administrative
  domains.
  
  That really sounds like an accident waiting to happen...
 
 If you are concerned about that, then don't make use of a centralized 
 keystore.
 
 You may be a security expert and have a deeper understanding of this 
 than I do, but from my limited experience and knowledge of security 
 audits and risk assessment, if you don't trust your system 
 administrators then you have a whole heap of other issues you need to 
 contend with.
 
 Consider that the FreeIPA server is probably *more* secure than the 
 user-accessible systems and file servers.  If someone with 
 administrative (root) privs for the part of the system where I store my 
 passphrase encrypted private key would be the kind of person who would 
 take the private key from a central keystore, if it existed, then do 
 you not think they could get my passphrase and/or cleartext private key 
 from the system *without* a central keystore?
 
 This is not to say there aren't arguments against it: a policy mix up 
 or a bug in the central keystore could lead to *all* users having their 
 private keys compromised, and an admin who can dip in and grab private 
 keys without any evidence would also be bad, but hopefully the Audit 
 part of IPA means that any access to private keys will be securely 
 logged, and flagged if they are by users other than the owner of the 
 private key.
 
 This is a topic that is very important to me, so I'm quite interested 
 to hear how my reasoning may be flawed, or to hear opinions from others.

As Adam pointed out, the default assumption is that no one is trusted.
But my main concern is not that the admins have access to your private
keys, but that they have access to your private keys *for an unrelated
domain*.

Even if both domains exist in your organization (e.g. CORP and ENG), you
are implicitly granting the admin of the CORP domain permission to
impersonate you on the ENG domain.

You're also significantly increasing the damage surface of a successful
attack against this domain. It's analogous to using the same password at
many major sites: compromise one and you have the keys to all of the
others.

So I guess what I'm saying is not Don't use centrally managed key
storage, but rather If you use the key anywhere but in this
administrative domain, do not put it in centrally-managed storage that
anyone but you can ever gain access to it.


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] Use of FreeIPA or FreeIPA LDAP server to hold private keys

2011-08-03 Thread Stephen Gallagher

On Wed, 2011-08-03 at 14:02 -0400, Ian Stokes-Rees wrote:
 
 
 On 8/3/11 1:46 PM, Stephen Gallagher wrote: 
  Well, there exist central storage approaches that don't allow even
  the local admin access to the data. The trade-off of course is that
  they can't reinstate your access if you forget the password. In
  other words, you can set a password that is used as a symmetric key
  for encrypting your data in the central store. It's still central
  and can be retrieved from anywhere, but only you know how to read
  it. 
 
 You still seem to be missing the relevance of unscrupulous
 administrators and compromised systems to man in the middle any
 interactions you have with this system.  Unless you never access the
 data yourself once the unscrupulous admin or attacker has gained
 access, then such a person can pretty easily intercept your password
 and get at your data.
 
 Ian

No, the way that such a system would work is that the password would
never be passed to the central server. Only the encrypted data would be
sent and received. All decryption would happen locally. The most a
man-in-the-middle attack could accomplish would be damaging the file so
it couldn't be decrypted anymore. That could accomplish a
denial-of-service, but not grant the attacker privileges to use your
keys.


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] Alternatives to freeipa

2011-07-08 Thread Stephen Gallagher

On Thu, 2011-07-07 at 23:50 +, Steven Jones wrote:
 8.
 
 I thought there was a better alternative to authconfig-tui...
 
 6
 
 I normally type setup, which gives you a splash popup that takes you to
 the auth config tool, but that dies silently.doing authconfig-tui
 shows you the python failuresat least I assume that's what the
 tracbacks ending in py are
 
 However if I dont blindly follow supports advice they wash their hands
 of the call.so I have to do it their way.


Last I heard, authconfig-tui was deprecated and could be expected not to
work with SSSD (aka for freeipa-client). What you want to use is either
authconfig-gtk (if you need a graphical interface) or just use
authconfig from the command-line and pass it the appropriate arguments.
See 'authconfig --help' for 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

[Freeipa-users] Proposal: drop DENY rules from HBAC

2011-06-29 Thread Stephen Gallagher

We discussed today on the FreeIPA status meeting the possibility of
dropping support for DENY rules from the HBAC specification. I'm
submitting it for discussion. Specifically, I'm looking to hear whether
there any any FreeIPA admins out there that have a strong opinion on
whether the DENY rules need to be included.

The current design of HBAC specifies that
1) If no ALLOW rules match, access is denied
2) If one or more ALLOW rules match and no DENY rules match, access is
allowed.
3) If one or more DENY rules match, access is denied.

Thus, DENY rules exist only to provide exceptions from the ALLOW rules.
There exists no ALLOW+DENY combination that cannot be constructed from
ALLOW rules only.[1]

DENY rules introduce a lot of edge-cases for evaluation. The most
important of which is the availability of the group membership for the
user logging in. Depending on the mechanism used to log in (for example,
GSSAPI over SSH or cross-realm Kerberos trust where the user is provided
by the PAC), SSSD's cache may not have a complete list of groups for
this user. If the login is occurring during offline mode (where SSSD
cannot contact the LDAP server to refresh the user's groups), SSSD
cannot determine whether DENY rules would match for the user. This
therefore translates into a potential security issue.

We implemented a workaround in the SSSD evaluator to resolve this by
guaranteeing that we do a full lookup of all groups referenced by rules
while we are retrieving the rules from FreeIPA. However, this requires
at least one additional lookup against the LDAP server (possibly many if
there is need to resolve nestings). This results in a significantly
slower login while online.

We also have issues related to source host evaluation. Some applications
will provide an IP address instead of a hostname in the pam_rhost
attribute. Our only recourse here is to perform a reverse-DNS lookup to
try and identify the real hostname(s) of the server. However, in many
real-world environments, reverse DNS is unavailable or misconfigured. In
the case of ALLOW rules, this would lead to a match failure and an
implicit denial. However, a failure to properly match a DENY rule can
result in unexpected access being granted. This is a potentially serious
security issue.

Given these edge cases (and performance issues of the noted workaround),
I propose that we should drop DENY rules from the HBAC specification and
limit ourselves only to ALLOW rules (which are much safer). Beyond the
obvious advantages for our implementation, I believe that this will be
less complex for users to write their rules.


[1] Some rules are complex to simulate, such as Allow access from all
PAM services EXCEPT telnet. But in a sane environment, all access
should be via whitelist. If a customer is using an exception rule, they
should re-evaluate this.


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] kinit working, but ipa-client-install not (client not found)

2011-06-23 Thread Stephen Gallagher

On Thu, 2011-06-23 at 15:26 +0200, Pieter Baele wrote:
 My new freeipa installation is working (server + kinit on a host where
 I configured krb5.conf manually)
 but ipa-client-install gives the typical Kerberos error:
 
 kinit: Client not found in Kerberos database while getting initial credentials
 
 Both hosts are resolvable


What are you passing to ipa-client-install? You need to make sure you've
specified -p admin principal and -W in order to get the appropriate
credentials.


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 v other methods

2011-06-23 Thread Stephen Gallagher

On Thu, 2011-06-23 at 21:17 +, Steven Jones wrote:
 Hi,
 
 looking at sssd enforcing the HBAC, is it possible to [easily] or even
 possible to achieve the same thing with say openlap or 389?

Right now, the SSSD is making certain assumptions that the server
providing the HBAC rules is an IPA server. However, I know that JR
Aquino wrote a pam_python module a while ago that works (without offline
capabilities) with the current HBAC approach.

Things will get a little more complex when the HBAC rules are extended
to support time ranges, though. But there's no firm timeline on that
yet.


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] Configuring a Fedora 15 client to connect to a FreeIPA 1.2 server

On Tue, 2011-06-21 at 11:06 -0400, Dan Scott wrote:
 Hi,
 
 I'm still running a FreeIPA 1.2 server but have started installing
 Fedora 15 clients and am trying to figure out how to manually setup
 the Krb/LDAP configuration.
 
 I've run the 'authconfig-tui' command and manually setup Krb
 authentication and LDAP authorisation, using DNS discovery for the
 servers. The authentication is working correctly, but when I run 'id
 $USERNAME' I don't receive the correct groups, so I believe that
 Kerberos is working, but the LDAP configuration is wrong. I've turned
 the sssd loglevel up to 100, but I can't figure out why I'm not
 getting the correct groups
 
 My system has a variety of files and I'm not sure which are still in use:
 
 /etc/krb5.conf
 /etc/pam_ldap.conf
 /etc/sssd/sssd.conf
 
 On Fedora 14 and earlier, there used to be an '/etc/nss_ldap.conf' -
 this is not present on F15.
 
 Can anyone help me figure out how to get the group lookups working?


Probably you need to add ldap_schema=rfc2307bis into the
[domain/default] section of /etc/sssd/sssd.conf.

If you just set authconfig up as an LDAP server, it defaults to
ldap_schema = rfc2307, which uses a different attribute on the server to
contain group memberships.


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] Configuring a Fedora 15 client to connect to a FreeIPA 1.2 server

On Tue, 2011-06-21 at 11:31 -0400, Dan Scott wrote:
 Hi,
 
 On Tue, Jun 21, 2011 at 11:20, Stephen Gallagher sgall...@redhat.com wrote:
  On Tue, 2011-06-21 at 11:06 -0400, Dan Scott wrote:
  Hi,
 
  I'm still running a FreeIPA 1.2 server but have started installing
  Fedora 15 clients and am trying to figure out how to manually setup
  the Krb/LDAP configuration.
 
  I've run the 'authconfig-tui' command and manually setup Krb
  authentication and LDAP authorisation, using DNS discovery for the
  servers. The authentication is working correctly, but when I run 'id
  $USERNAME' I don't receive the correct groups, so I believe that
  Kerberos is working, but the LDAP configuration is wrong. I've turned
  the sssd loglevel up to 100, but I can't figure out why I'm not
  getting the correct groups
 
  My system has a variety of files and I'm not sure which are still in use:
 
  /etc/krb5.conf
  /etc/pam_ldap.conf
  /etc/sssd/sssd.conf
 
  On Fedora 14 and earlier, there used to be an '/etc/nss_ldap.conf' -
  this is not present on F15.
 
  Can anyone help me figure out how to get the group lookups working?
 
 
  Probably you need to add ldap_schema=rfc2307bis into the
  [domain/default] section of /etc/sssd/sssd.conf.
 
  If you just set authconfig up as an LDAP server, it defaults to
  ldap_schema = rfc2307, which uses a different attribute on the server to
  contain group memberships.
 
 Thanks, but I've tried both of those entries - it doesn't appear to
 make any difference.
 
 Dan


Could you attach your
(sanitized) /etc/sssd/sssd.conf, /etc/krb5.conf, /etc/nsswitch.conf
and /etc/pam.d/system-auth?


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] Configuring a Fedora 15 client to connect to a FreeIPA 1.2 server

On Tue, 2011-06-21 at 11:58 -0400, Dan Scott wrote:
 On Tue, Jun 21, 2011 at 11:37, Stephen Gallagher sgall...@redhat.com wrote:
  On Tue, 2011-06-21 at 11:31 -0400, Dan Scott wrote:
  Hi,
 
  On Tue, Jun 21, 2011 at 11:20, Stephen Gallagher sgall...@redhat.com 
  wrote:
   On Tue, 2011-06-21 at 11:06 -0400, Dan Scott wrote:
   Hi,
  
   I'm still running a FreeIPA 1.2 server but have started installing
   Fedora 15 clients and am trying to figure out how to manually setup
   the Krb/LDAP configuration.
  
   I've run the 'authconfig-tui' command and manually setup Krb
   authentication and LDAP authorisation, using DNS discovery for the
   servers. The authentication is working correctly, but when I run 'id
   $USERNAME' I don't receive the correct groups, so I believe that
   Kerberos is working, but the LDAP configuration is wrong. I've turned
   the sssd loglevel up to 100, but I can't figure out why I'm not
   getting the correct groups
  
   My system has a variety of files and I'm not sure which are still in 
   use:
  
   /etc/krb5.conf
   /etc/pam_ldap.conf
   /etc/sssd/sssd.conf
  
   On Fedora 14 and earlier, there used to be an '/etc/nss_ldap.conf' -
   this is not present on F15.
  
   Can anyone help me figure out how to get the group lookups working?
  
  
   Probably you need to add ldap_schema=rfc2307bis into the
   [domain/default] section of /etc/sssd/sssd.conf.
  
   If you just set authconfig up as an LDAP server, it defaults to
   ldap_schema = rfc2307, which uses a different attribute on the server to
   contain group memberships.
 
  Thanks, but I've tried both of those entries - it doesn't appear to
  make any difference.
 
  Dan
 
 
  Could you attach your
  (sanitized) /etc/sssd/sssd.conf, /etc/krb5.conf, /etc/nsswitch.conf
  and /etc/pam.d/system-auth?
 
 Attached, thanks. The only changes are domain names and 'dc=*' entries.
 
 One thing that I just noticed, the system-auth file has pam_krb5.so
 entries, previously, these were pam_sss.so - I've tried using both,
 but neither appears to work.
 
 Thanks,
 
 Dan


Your /etc/nsswitch.conf is wrong. I just noticed that you were using
authconfig-tui which is deprecated upstream and does not properly set up
SSSD. Only 'authconfig' (command-line) or 'authconfig-gtk' (GUI) works
properly. Feel free to file a bug against authconfig.

/etc/nsswitch.conf needs to specify 'sss' instead of 'ldap' to use SSSD.
Similarly system-auth needs to use pam_sss.so, not pam_krb5.so.

If you run 'authconfig --enablesssd --enablesssdauth --update' you
should be fine. This will update the config files with the correct
SSSD-related settings.


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] Configuring a Fedora 15 client to connect to a FreeIPA 1.2 server