Re: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix

2012-10-31 Thread Stephen Ingram 
On Wed, Oct 31, 2012 at 10:21 PM, Peter Brown  wrote:
> On 1 November 2012 15:07, Stephen Ingram  wrote:
>>
>> On Wed, Oct 31, 2012 at 6:25 PM, Peter Brown  wrote:
>> > On 1 November 2012 08:20, Stephen Ingram  wrote:
>> >>
>> >> On Tue, Oct 30, 2012 at 6:34 PM, Peter Brown 
>> >> wrote:
>> >> > Hi everyone,
>> >> >
>> >> > I have been trying to work out how to achieve this.
>> >> > I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix
>> >> > and
>> >> > dovecot on my new mail server authenticating against Freeipa.
>> >> > One last thing I would love to do it pull down the virtual users and
>> >> > aliases
>> >> > for the domains my mailserver will be serving from freeipa.
>> >> > Is this possible?
>> >> > Is this all automatic due to sssd looking up the user details in the
>> >> > ds?
>> >> > Does it do the same for domains and email aliases or will I need
>> >> > extra
>> >> > lookups to achieve this.
>> >>
>> >> I've recently built an entire mail system around FreeIPA and it works
>> >> great. There are two parts to be concerned with:
>> >>
>> >> 1. Authentication - With Postfix, this is handled by saslauthd which
>> >> can authenticate against Kerberos (using or not using sssd). I used
>> >> Cyrus-IMAP for the mailstore which also uses saslauthd. Doveccot has
>> >> it's own sasl built in which can authenticate against Kerberos or
>> >> LDAP, thus it should work with IPA.
>> >
>> >
>> > I have dovecot authing against freeipa (via pam)and I setup a sasl auth
>> > instance in dovecot and have postfix authing against that.
>> > I figured why setup another sasl auth daemon when dovecot can do it for
>> > me
>> > so they effectively use the same authentication source.
>> >
>> >> 2. Configuration - With Postfix, you can set all different areas (e.g.
>> >> virtual, aliases, etc.) to use LDAP lookup of configuration
>> >> information. You are typically searching for the email address (mail
>> >> attribute in IPA) and your search will generally return the userid
>> >> (uid attribute) of where the mail is to be stored. I don't believe
>> >> that Dovecot or Cyrus-IMAP have any way of maintaining any
>> >> configuration in LDAP so you generally have to setup mailboxes and
>> >> authorization information by hand using their tools.
>> >
>> >
>> > I have most of that worked out but getting delivery addresses for
>> > domains
>> > that aren't the base is proving tricky.
>> > It's looking like I will need to add some extra schemas to the ds so i
>> > can
>> > add the delivery domain to each user and somehow use that to construct
>> > the
>> > delivery address.
>> > I am not sure I can do that though.
>>
>> I didn't really have to add anything except for one extra attribute.
>> You can group your users into user groups representing the domains
>> they belong to such that Postfix can query whether or not to accept
>> for a domain or not. I added mailAlternateAddress for aliases rather
>> than user multi-value attribute mail so I can have a "master" email
>> address for each user. It was easy to do with the existing schema
>> (mailRecipient objectclass). BTW if you haven't already figured it
>> out, postmap -q is your friend when setting up your LDAP config in
>> Postfix. Just keep adjusting everything until you get the answer you
>> (and Postfix) expect.
>
>
> I discovered that attribute when I was digging around in the ldif files and
> I was just wondering why they didn't use that for setting aliases.
> It would certainly make my ldap queries for postfix a lot simpler.
>
> I added the mailRecipient class to the defaults for users and tried to use
> the ipa user-mod --setattr=mailAlternateAddress= and it is telling me
>
> ipa: ERROR: attribute "mailAlternateAddress" not allowed
>
> I have also trying to set a few other non standard attributes that seem to
> be in the default schemas already and they all give me the same error.
> Am I missing something?

Yes. You need to add the objectclass first, then the attribute will be
available. We add the objectclass to each mail user (some of our users
don't have mail) and also to the user group (the domain) such that
Postfix can easily find by using the objectclass as a filter. So:

ipa user-mod --addattr=objectclass=mailRecipient

I've patched IPA to include the mailAlternateAddress so when I add an
alias that attribute is added automatically. If you don't want to
patch then you'll need to also:

ipa user-mod --addattr=mailAlternateAddress

>
>
>> > I am half tempted to add the extra components of 389-ds and see it that
>> > will
>> > let me do what I need.
>> >
>> > On a side note the freeipa lads seem to be working out how to add
>> > multitenancy support so it will be capable of serving multiple separate
>> > Kerberos principals.
>> > That would help a lot but I need to cobble something together now.
>>
>> Yes, if you want unique uid's within each domain you'll have to wait
>> for that. I gave up on that notion and simply require unique uids for
>> every user re

Re: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix

2012-10-31 Thread Peter Brown 
On 1 November 2012 15:07, Stephen Ingram  wrote:

> On Wed, Oct 31, 2012 at 6:25 PM, Peter Brown  wrote:
> > On 1 November 2012 08:20, Stephen Ingram  wrote:
> >>
> >> On Tue, Oct 30, 2012 at 6:34 PM, Peter Brown 
> wrote:
> >> > Hi everyone,
> >> >
> >> > I have been trying to work out how to achieve this.
> >> > I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix
> and
> >> > dovecot on my new mail server authenticating against Freeipa.
> >> > One last thing I would love to do it pull down the virtual users and
> >> > aliases
> >> > for the domains my mailserver will be serving from freeipa.
> >> > Is this possible?
> >> > Is this all automatic due to sssd looking up the user details in the
> ds?
> >> > Does it do the same for domains and email aliases or will I need extra
> >> > lookups to achieve this.
> >>
> >> I've recently built an entire mail system around FreeIPA and it works
> >> great. There are two parts to be concerned with:
> >>
> >> 1. Authentication - With Postfix, this is handled by saslauthd which
> >> can authenticate against Kerberos (using or not using sssd). I used
> >> Cyrus-IMAP for the mailstore which also uses saslauthd. Doveccot has
> >> it's own sasl built in which can authenticate against Kerberos or
> >> LDAP, thus it should work with IPA.
> >
> >
> > I have dovecot authing against freeipa (via pam)and I setup a sasl auth
> > instance in dovecot and have postfix authing against that.
> > I figured why setup another sasl auth daemon when dovecot can do it for
> me
> > so they effectively use the same authentication source.
> >
> >> 2. Configuration - With Postfix, you can set all different areas (e.g.
> >> virtual, aliases, etc.) to use LDAP lookup of configuration
> >> information. You are typically searching for the email address (mail
> >> attribute in IPA) and your search will generally return the userid
> >> (uid attribute) of where the mail is to be stored. I don't believe
> >> that Dovecot or Cyrus-IMAP have any way of maintaining any
> >> configuration in LDAP so you generally have to setup mailboxes and
> >> authorization information by hand using their tools.
> >
> >
> > I have most of that worked out but getting delivery addresses for domains
> > that aren't the base is proving tricky.
> > It's looking like I will need to add some extra schemas to the ds so i
> can
> > add the delivery domain to each user and somehow use that to construct
> the
> > delivery address.
> > I am not sure I can do that though.
>
> I didn't really have to add anything except for one extra attribute.
> You can group your users into user groups representing the domains
> they belong to such that Postfix can query whether or not to accept
> for a domain or not. I added mailAlternateAddress for aliases rather
> than user multi-value attribute mail so I can have a "master" email
> address for each user. It was easy to do with the existing schema
> (mailRecipient objectclass). BTW if you haven't already figured it
> out, postmap -q is your friend when setting up your LDAP config in
> Postfix. Just keep adjusting everything until you get the answer you
> (and Postfix) expect.
>

I discovered that attribute when I was digging around in the ldif files and
I was just wondering why they didn't use that for setting aliases.
It would certainly make my ldap queries for postfix a lot simpler.

I added the mailRecipient class to the defaults for users and tried to use
the ipa user-mod --setattr=mailAlternateAddress= and it is telling me

ipa: ERROR: attribute "mailAlternateAddress" not allowed

I have also trying to set a few other non standard attributes that seem to
be in the default schemas already and they all give me the same error.
Am I missing something?


> I am half tempted to add the extra components of 389-ds and see it that
> will
> > let me do what I need.
> >
> > On a side note the freeipa lads seem to be working out how to add
> > multitenancy support so it will be capable of serving multiple separate
> > Kerberos principals.
> > That would help a lot but I need to cobble something together now.
>
> Yes, if you want unique uid's within each domain you'll have to wait
> for that. I gave up on that notion and simply require unique uids for
> every user regardless of domain and deliver to single domain style
> mail store setup.
>


yeah that's tempting but I need to have separate domains.


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

Re: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix

2012-10-31 Thread Stephen Ingram 
On Wed, Oct 31, 2012 at 6:25 PM, Peter Brown  wrote:
> On 1 November 2012 08:20, Stephen Ingram  wrote:
>>
>> On Tue, Oct 30, 2012 at 6:34 PM, Peter Brown  wrote:
>> > Hi everyone,
>> >
>> > I have been trying to work out how to achieve this.
>> > I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix and
>> > dovecot on my new mail server authenticating against Freeipa.
>> > One last thing I would love to do it pull down the virtual users and
>> > aliases
>> > for the domains my mailserver will be serving from freeipa.
>> > Is this possible?
>> > Is this all automatic due to sssd looking up the user details in the ds?
>> > Does it do the same for domains and email aliases or will I need extra
>> > lookups to achieve this.
>>
>> I've recently built an entire mail system around FreeIPA and it works
>> great. There are two parts to be concerned with:
>>
>> 1. Authentication - With Postfix, this is handled by saslauthd which
>> can authenticate against Kerberos (using or not using sssd). I used
>> Cyrus-IMAP for the mailstore which also uses saslauthd. Doveccot has
>> it's own sasl built in which can authenticate against Kerberos or
>> LDAP, thus it should work with IPA.
>
>
> I have dovecot authing against freeipa (via pam)and I setup a sasl auth
> instance in dovecot and have postfix authing against that.
> I figured why setup another sasl auth daemon when dovecot can do it for me
> so they effectively use the same authentication source.
>
>> 2. Configuration - With Postfix, you can set all different areas (e.g.
>> virtual, aliases, etc.) to use LDAP lookup of configuration
>> information. You are typically searching for the email address (mail
>> attribute in IPA) and your search will generally return the userid
>> (uid attribute) of where the mail is to be stored. I don't believe
>> that Dovecot or Cyrus-IMAP have any way of maintaining any
>> configuration in LDAP so you generally have to setup mailboxes and
>> authorization information by hand using their tools.
>
>
> I have most of that worked out but getting delivery addresses for domains
> that aren't the base is proving tricky.
> It's looking like I will need to add some extra schemas to the ds so i can
> add the delivery domain to each user and somehow use that to construct the
> delivery address.
> I am not sure I can do that though.

I didn't really have to add anything except for one extra attribute.
You can group your users into user groups representing the domains
they belong to such that Postfix can query whether or not to accept
for a domain or not. I added mailAlternateAddress for aliases rather
than user multi-value attribute mail so I can have a "master" email
address for each user. It was easy to do with the existing schema
(mailRecipient objectclass). BTW if you haven't already figured it
out, postmap -q is your friend when setting up your LDAP config in
Postfix. Just keep adjusting everything until you get the answer you
(and Postfix) expect.

> I am half tempted to add the extra components of 389-ds and see it that will
> let me do what I need.
>
> On a side note the freeipa lads seem to be working out how to add
> multitenancy support so it will be capable of serving multiple separate
> Kerberos principals.
> That would help a lot but I need to cobble something together now.

Yes, if you want unique uid's within each domain you'll have to wait
for that. I gave up on that notion and simply require unique uids for
every user regardless of domain and deliver to single domain style
mail store setup.

Steve

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

Re: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix

2012-10-31 Thread Stephen Ingram 
On Tue, Oct 30, 2012 at 6:34 PM, Peter Brown  wrote:
> Hi everyone,
>
> I have been trying to work out how to achieve this.
> I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix and
> dovecot on my new mail server authenticating against Freeipa.
> One last thing I would love to do it pull down the virtual users and aliases
> for the domains my mailserver will be serving from freeipa.
> Is this possible?
> Is this all automatic due to sssd looking up the user details in the ds?
> Does it do the same for domains and email aliases or will I need extra
> lookups to achieve this.

I've recently built an entire mail system around FreeIPA and it works
great. There are two parts to be concerned with:

1. Authentication - With Postfix, this is handled by saslauthd which
can authenticate against Kerberos (using or not using sssd). I used
Cyrus-IMAP for the mailstore which also uses saslauthd. Doveccot has
it's own sasl built in which can authenticate against Kerberos or
LDAP, thus it should work with IPA.

2. Configuration - With Postfix, you can set all different areas (e.g.
virtual, aliases, etc.) to use LDAP lookup of configuration
information. You are typically searching for the email address (mail
attribute in IPA) and your search will generally return the userid
(uid attribute) of where the mail is to be stored. I don't believe
that Dovecot or Cyrus-IMAP have any way of maintaining any
configuration in LDAP so you generally have to setup mailboxes and
authorization information by hand using their tools.

Steve

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

Re: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix

2012-10-31 Thread Dmitri Pal 
On 10/30/2012 09:34 PM, Peter Brown wrote:
> Hi everyone,
>
> I have been trying to work out how to achieve this.
> I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix
> and dovecot on my new mail server authenticating against Freeipa.
> One last thing I would love to do it pull down the virtual users and
> aliases for the domains my mailserver will be serving from freeipa.
> Is this possible?
> Is this all automatic due to sssd looking up the user details in the ds?
> Does it do the same for domains and email aliases or will I need extra
> lookups to achieve this.
>
> Thanks in advance.
> Pete.
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
I am not sure if anything on those pages is relevant to what you are
trying to accomplish but they talk about FreeIPA and dovecot integration:
http://www.freeipa.org/page/Dovecot_Integration
http://www.freeipa.org/page/Dovecot_IMAPS_Integration_with_FreeIPA_using_Single_Sign_On
If not the author of the pages - Dale might have more experience with
the similar environment and might have tried what you are looking for.

HTH

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-users] Sudo not working

2012-10-31 Thread Rob Crittenden 

Bret Wortman wrote:

[root@fs1 etc]# more /etc/ldap.conf
sudoers_debug: 1
[root@fs1 etc]# ls -l /etc/ldap.conf
-rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf

Where should I see the extra output? I've had this set since last Friday
and I'm not seeing any difference.


Move the contents of /etc/nslcd.conf to this file and add ldap to 
sudoers in /etc/nsswitch.conf.


rob



On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden mailto:rcrit...@redhat.com>> wrote:

Bret Wortman wrote:

F17.


I think you want /etc/ldap.conf then. The easiest way to be sure the
right file is being used is to add sudoers_debug 1 to the file. This
will present a lot of extra output so you'll know the file is being
read.

rob


On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden
mailto:rcrit...@redhat.com>
>> wrote:

 Bret Wortman wrote:

 I had enabled debugging of sudo but am not clear on
where that
 debugging
 is going. It's not stdout, and I'm not seeing anything in
 /var/log/messages.

 I'll try switching to SSS and see what that gets me.


 What distro is this? If it is RHEL 6.3 then put the
configuration
 into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are
 incorrect (we are working on getting them fixed).

 rob



 On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher
 mailto:sgall...@redhat.com>
>
   
 
  

  sudoers_base ou=SUDOers,dc=wedgeofli,dc=me


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


  

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

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

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




 --
 Bret Wortman
 The Damascus Group
 Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman




 --
 Bret Wortman
 The Damascus Group
 Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman



 ___
 Freeipa-users mailing list
Freeipa-users@redhat.com 
>
https://www.redhat.com/mail

Re: [Freeipa-users] Sudo not working

2012-10-31 Thread Bret Wortman 
[root@fs1 etc]# more /etc/ldap.conf
sudoers_debug: 1
[root@fs1 etc]# ls -l /etc/ldap.conf
-rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf

Where should I see the extra output? I've had this set since last Friday
and I'm not seeing any difference.

On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden  wrote:

> Bret Wortman wrote:
>
>> F17.
>>
>
> I think you want /etc/ldap.conf then. The easiest way to be sure the right
> file is being used is to add sudoers_debug 1 to the file. This will present
> a lot of extra output so you'll know the file is being read.
>
> rob
>
>
>> On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden > > wrote:
>>
>> Bret Wortman wrote:
>>
>> I had enabled debugging of sudo but am not clear on where that
>> debugging
>> is going. It's not stdout, and I'm not seeing anything in
>> /var/log/messages.
>>
>> I'll try switching to SSS and see what that gets me.
>>
>>
>> What distro is this? If it is RHEL 6.3 then put the configuration
>> into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are
>> incorrect (we are working on getting them fixed).
>>
>> rob
>>
>>
>>
>> On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher
>> mailto:sgall...@redhat.com>
>> >> wrote:
>>
>>  On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote:
>>
>>  I'm pretty certain there's a painfully simple solution
>> to this that
>>  I'm not seeing, but my current configuration isn't
>> picking up the
>>  freeipa sudoer rule that I've set.
>>
>>  /etc/nsswitch.conf specifies:
>>sudoers:files ldap
>>
>>  /etc/nslcd.conf contains:
>>
>>  binddn
>> uid=sudo,cn=sysaccounts,cn=___**_etc,dc=wedgeofli,dc=me
>>
>>
>>  bindpw password
>>
>>  ssl start_tls
>>  tls_cacertfile /etc/ipa/ca.crt
>>  tls_checkpeer yes
>>
>>  bind_timelimit 5
>>  timelimit 15
>>
>>  uri ldap://fs1.wedgeofli.me 
>> 
>>  
>>
>>  sudoers_base ou=SUDOers,dc=wedgeofli,dc=me
>>
>>
>>  The sssd_DOMAIN.log file contains this when I try to
>> sudo:
>>
>>
>>  
>>
>>  The SSSD logs aren't showing anything wrong because they have
>>  nothing to do with the execution of the SUDO rules in this
>>  situation. All the SSSD is doing is verifying the
>> authentication
>>  (when sudo prompts you for your password).
>>
>>  The problem with the rule is most likely happening inside
>> SUDO
>>  itself. When you specify 'sudoers: files, ldap' in
>> nsswitch.conf,
>>  it's telling SUDO to use its own internal LDAP driver to
>> look up the
>>  rules. So you need to check sudo logs to see what's happening
>>  (probably you will need to enable debug logging in
>> /etc/sudo.conf).
>>
>>  Recent versions of SUDO (1.8.6 and later) have support for
>> setting
>>  'sudoers: files, sss' in nsswitch.conf which DOES use SSSD
>> (1.9.0
>>  and later) for lookups (and caching) of sudo rules.
>>
>>
>>
>>
>> --
>> Bret Wortman
>> The Damascus Group
>> Fairfax, VA
>> http://bretwortman.com/
>> http://twitter.com/BretWortman
>>
>>
>>
>>
>> --
>> Bret Wortman
>> The Damascus Group
>> Fairfax, VA
>> http://bretwortman.com/
>> http://twitter.com/BretWortman
>>
>>
>>
>> __**___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com 
>> > >
>> 
>> https://www.redhat.com/__**mailman/listinfo/freeipa-users
>>
>> 
>> 
>> **>
>>
>>
>>
>>
>>
>> --
>> Bret Wortman
>> The Damascus Group
>> Fairfax, VA
>> http://bretwortman.com/
>> http://twitter.com/BretWortman
>>
>>
>>
>> __**_
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/**mailman/listinfo/freeipa-users
>>
>>
>


-- 
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo not working

2012-10-31 Thread Rob Crittenden 

Bret Wortman wrote:

F17.


I think you want /etc/ldap.conf then. The easiest way to be sure the 
right file is being used is to add sudoers_debug 1 to the file. This 
will present a lot of extra output so you'll know the file is being read.


rob



On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden mailto:rcrit...@redhat.com>> wrote:

Bret Wortman wrote:

I had enabled debugging of sudo but am not clear on where that
debugging
is going. It's not stdout, and I'm not seeing anything in
/var/log/messages.

I'll try switching to SSS and see what that gets me.


What distro is this? If it is RHEL 6.3 then put the configuration
into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are
incorrect (we are working on getting them fixed).

rob



On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher
mailto:sgall...@redhat.com>
>> wrote:

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

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

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

 /etc/nslcd.conf contains:

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

 bindpw password

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

 bind_timelimit 5
 timelimit 15

 uri ldap://fs1.wedgeofli.me 

 

 sudoers_base ou=SUDOers,dc=wedgeofli,dc=me


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


 

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

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

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




--
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman




--
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman



_
Freeipa-users mailing list
Freeipa-users@redhat.com 
https://www.redhat.com/__mailman/listinfo/freeipa-users






--
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman



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



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

Re: [Freeipa-users] Sudo not working

2012-10-31 Thread Bret Wortman 
F17.

On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden  wrote:

> Bret Wortman wrote:
>
>> I had enabled debugging of sudo but am not clear on where that debugging
>> is going. It's not stdout, and I'm not seeing anything in
>> /var/log/messages.
>>
>> I'll try switching to SSS and see what that gets me.
>>
>
> What distro is this? If it is RHEL 6.3 then put the configuration into
> /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we are
> working on getting them fixed).
>
> rob
>
>
>>
>> On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher > > wrote:
>>
>> On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote:
>>
>> I'm pretty certain there's a painfully simple solution to this
>> that
>> I'm not seeing, but my current configuration isn't picking up the
>> freeipa sudoer rule that I've set.
>>
>> /etc/nsswitch.conf specifies:
>>   sudoers:files ldap
>>
>> /etc/nslcd.conf contains:
>>
>> binddn uid=sudo,cn=sysaccounts,cn=__**etc,dc=wedgeofli,dc=me
>>
>> bindpw password
>>
>> ssl start_tls
>> tls_cacertfile /etc/ipa/ca.crt
>> tls_checkpeer yes
>>
>> bind_timelimit 5
>> timelimit 15
>>
>> uri ldap://fs1.wedgeofli.me 
>> 
>>
>> sudoers_base ou=SUDOers,dc=wedgeofli,dc=me
>>
>>
>> The sssd_DOMAIN.log file contains this when I try to sudo:
>>
>>
>> 
>>
>> The SSSD logs aren't showing anything wrong because they have
>> nothing to do with the execution of the SUDO rules in this
>> situation. All the SSSD is doing is verifying the authentication
>> (when sudo prompts you for your password).
>>
>> The problem with the rule is most likely happening inside SUDO
>> itself. When you specify 'sudoers: files, ldap' in nsswitch.conf,
>> it's telling SUDO to use its own internal LDAP driver to look up the
>> rules. So you need to check sudo logs to see what's happening
>> (probably you will need to enable debug logging in /etc/sudo.conf).
>>
>> Recent versions of SUDO (1.8.6 and later) have support for setting
>> 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0
>> and later) for lookups (and caching) of sudo rules.
>>
>>
>>
>>
>> --
>> Bret Wortman
>> The Damascus Group
>> Fairfax, VA
>> http://bretwortman.com/
>> http://twitter.com/BretWortman
>>
>>
>>
>>
>> --
>> Bret Wortman
>> The Damascus Group
>> Fairfax, VA
>> http://bretwortman.com/
>> http://twitter.com/BretWortman
>>
>>
>>
>> __**_
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/**mailman/listinfo/freeipa-users
>>
>>
>


-- 
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo not working

2012-10-31 Thread Rob Crittenden 

Bret Wortman wrote:

I had enabled debugging of sudo but am not clear on where that debugging
is going. It's not stdout, and I'm not seeing anything in /var/log/messages.

I'll try switching to SSS and see what that gets me.


What distro is this? If it is RHEL 6.3 then put the configuration into 
/etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we 
are working on getting them fixed).


rob




On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher mailto:sgall...@redhat.com>> wrote:

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

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

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

/etc/nslcd.conf contains:

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

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

bind_timelimit 5
timelimit 15

uri ldap://fs1.wedgeofli.me 


sudoers_base ou=SUDOers,dc=wedgeofli,dc=me


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




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

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

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




--
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman




--
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman



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



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

[Freeipa-users] Sudo not working

2012-10-31 Thread Bret Wortman 
I had enabled debugging of sudo but am not clear on where that debugging is
going. It's not stdout, and I'm not seeing anything in /var/log/messages.

I'll try switching to SSS and see what that gets me.


On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher wrote:

> On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote:
>
>> I'm pretty certain there's a painfully simple solution to this that
>> I'm not seeing, but my current configuration isn't picking up the
>> freeipa sudoer rule that I've set.
>>
>> /etc/nsswitch.conf specifies:
>>  sudoers:files ldap
>>
>> /etc/nslcd.conf contains:
>>
>> binddn uid=sudo,cn=sysaccounts,cn=**etc,dc=wedgeofli,dc=me
>> bindpw password
>>
>> ssl start_tls
>> tls_cacertfile /etc/ipa/ca.crt
>> tls_checkpeer yes
>>
>> bind_timelimit 5
>> timelimit 15
>>
>> uri ldap://fs1.wedgeofli.me 
>>
>> sudoers_base ou=SUDOers,dc=wedgeofli,dc=me
>>
>>
>> The sssd_DOMAIN.log file contains this when I try to sudo:
>>
>>
> 
>
> The SSSD logs aren't showing anything wrong because they have nothing to
> do with the execution of the SUDO rules in this situation. All the SSSD is
> doing is verifying the authentication (when sudo prompts you for your
> password).
>
> The problem with the rule is most likely happening inside SUDO itself.
> When you specify 'sudoers: files, ldap' in nsswitch.conf, it's telling SUDO
> to use its own internal LDAP driver to look up the rules. So you need to
> check sudo logs to see what's happening (probably you will need to enable
> debug logging in /etc/sudo.conf).
>
> Recent versions of SUDO (1.8.6 and later) have support for setting
> 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0 and
> later) for lookups (and caching) of sudo rules.
>



-- 
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman




-- 
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo not working

2012-10-31 Thread Stephen Gallagher 

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

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

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

/etc/nslcd.conf contains:

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

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

bind_timelimit 5
timelimit 15

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


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





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


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


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


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

[Freeipa-users] Sudo not working

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

/etc/nsswitch.conf specifies:

 sudoers:files ldap

/etc/nslcd.conf contains:

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

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

bind_timelimit 5
timelimit 15

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


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

(Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_users]
(0x0400): Search users with filter:
(&(objectclass=user)(&(!(dataExpireTimestamp=0))(dataExpireTimestamp<=1351698653)(!(lastLogin=*
(Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_users]
(0x0400): No such entry
(Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_groups]
(0x0400): Search groups with filter:
(&(objectclass=group)(&(!(dataExpireTimestamp=0))(dataExpireTimestamp<=1351698653)))
(Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [cleanup_groups]
(0x0100): Found 3 expired group entries!
(Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_users]
(0x0400): Search users with filter:
(&(objectclass=user)(|(memberOf=name=nonexpiring,cn=groups,cn=wedgeofli.me
,cn=sysdb)(gidNumber=501)))
(Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_users]
(0x0400): Search users with filter:
(&(objectclass=user)(|(memberOf=name=jtbays,cn=groups,cn=wedgeofli.me
,cn=sysdb)(gidNumber=1002)))
(Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_users]
(0x0400): Search users with filter:
(&(objectclass=user)(|(memberOf=name=xmmgr,cn=groups,cn=wedgeofli.me
,cn=sysdb)(gidNumber=1015)))
(Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]]
[ldap_id_cleanup_set_timer] (0x0400): Scheduling next cleanup at
1351702253.2528
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [be_get_account_info]
(0x0100): Got request for [3][1][name=bretw]
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of '
fs1.wedgeofli.me' in files
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[set_server_common_status] (0x0100): Marking server 'fs1.wedgeofli.me' as
'resolving name'
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[set_server_common_status] (0x0100): Marking server 'fs1.wedgeofli.me' as
'name resolved'
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[be_resolve_server_done] (0x0200): Found address for server fs1.wedgeofli.me:
[192.168.2.129] TTL 7200
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [ipa_resolve_callback]
(0x0400): Constructed uri 'ldap://fs1.wedgeofli.me'
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sss_ldap_init_send]
(0x0400): Setting 6 seconds timeout for connecting
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(objectclass=*)][].
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg
set
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_kinit_send]
(0x0400): Attempting kinit (default, host/fs1.wedgeofli.me, WEDGEOFLI.ME,
86400)
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[be_resolve_server_done] (0x0200): Found address for server fs1.wedgeofli.me:
[192.168.2.129] TTL 7200
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [set_tgt_child_timeout]
(0x0400): Setting 6 seconds timeout for tgt child
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [write_pipe_handler]
(0x0400): All data has been sent!
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [read_pipe_handler]
(0x0400): EOF received, client finished
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_get_tgt_recv]
(0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_WEDGEOFLI.ME],
expired on [1351785056]
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sasl_bind_send]
(0x0100): Executing sasl bind mech: GSSAPI, user: host/fs1.wedgeofli.me
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [child_sig_handler]
(0x0100): child [17655] finished successfully.
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [fo_set_port_status]
(0x0100): Marking port 0 of server 'fs1.wedgeofli.me' as 'working'
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[set_server_common_status] (0x0100): Marking server 'fs1.wedgeofli.me' as
'working'
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[sdap_get_initgr_next_base] (0x0400): Searching for users with base
[cn=accounts,dc=wedgeofli,dc=me]
(Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]]
[sdap_get_generic_ext_step] (0x0400

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

2012-10-31 Thread Bret Wortman 
That's what I needed to know. We'll set a system-wide policy and be done
with it. Thanks!

On Wed, Oct 31, 2012 at 9:43 AM, Stephen Gallagher wrote:

> On Wed 31 Oct 2012 08:56:14 AM EDT, Bret Wortman wrote:
>
>> Has anyone set things up so that individual users have the option to
>> automount a homedir or have one autocreated on each system they use
>> for them? I have some users who prefer one way and others who prefer
>> the other. Both have valid reasons and I'd rather not make an
>> authoritarian decision for one over the other.
>>
>>  1. How could this be handled as a user option, set as the account is
>>
>> created or modified and open to adjustment later?
>>
>
> A feature could be added to SSSD to allow users to override the home
> directory location on individual clients. This feature would have to be
> subject to administrator approval in some way (to restrict where users
> could set their home directories and which users have this privilege). That
> requires some thought. Feel free to file an RFE at
> https://fedorahosted.org/sssd
>
>   2. How might this be handled as a login option, allowing the user to
>>
>> select their automounted homedir or a local homedir?
>>
>>
> This just isn't going to happen. Period.
>
> The location of the user's home directory is an integral part of the
> user's identity on the system. It cannot vary at login time. All sessions
> of the logged-in user (as well as any application that calls getpwnam())
> need to agree on this value or you will have problems.
>
>
>  Anyone already set this up and have it working well? I'd hate to spend
>> time re-inventing a wheel if there's already an excellent example in
>> the wild
>>
>>
>
> As a general rule, it's usually better to just make the decision on a
> per-system basis than a per-user basis. I.e. everyone who logs on to
> certain infrastructure systems will always use the automount home
> directory, but on personal systems they can be configured to not use
> automount.
>



-- 
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2012-10-31 Thread Stephen Gallagher 

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

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

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


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



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



This just isn't going to happen. Period.

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



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




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


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

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

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

   1. How could this be handled as a user option, set as the account is
   created or modified and open to adjustment later?
   2. How might this be handled as a login option, allowing the user to
   select their automounted homedir or a local homedir?

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

Thanks!


-- 
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix

2012-10-31 Thread Simo Sorce 
On Wed, 2012-10-31 at 11:34 +1000, Peter Brown wrote:
> Hi everyone,
> 
> 
> I have been trying to work out how to achieve this.
> I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix
> and dovecot on my new mail server authenticating against Freeipa.
> One last thing I would love to do it pull down the virtual users and
> aliases for the domains my mailserver will be serving from freeipa.
> Is this possible?
> Is this all automatic due to sssd looking up the user details in the
> ds?
> Does it do the same for domains and email aliases or will I need extra
> lookups to achieve this.

A loong time ago I sue the excellent support in postfix to route mail
based on data in ldap, however I have no idea how's dovecot support for
that.

FreeIPA will create a single domain for you atm, but you can indeed
associate any email address to a user, however sssd does not have any
facility to resolve a user by email address, so unless you just care
about the default domain (in which case you can lookup users via sssd
just like you would against /etc/passwd) I think you'll have to
configure your daemons to lookup data directly via ldap.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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