FreeIPA and postfix issue.

[Bob Rentschler]

This may be related to the issue discussed here:
https://lists.fedorahosted.org/archives/list/freeipa-
users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/

But it seems not to be, layer 8 is still open though.

Using the instructions here
https://www.dalemacartney.com/2013/03/14/deploying-postfix-with-ldap-free...
to enable postfix virtual users from freeIPA I seem to have hit a sticking
point in that postfix is unable to fetch the mail attribute.

this is the query filter I modified as per the referenced email in the
archive.

query_filter = (&(objectclass=posixaccount)(mail=%s))

When run from postmap it gets nothing. If I change it for testing to search
by uid or another attribute it works as expected. a simple filter like
(uid=%s) works everytime.

This ldapsearch run using the postfix servers keytab as credentials works
as well:

ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=org
'(&(objectclass=posixaccount)(|(mail=validuser(a)example.org)))'

The FreeIPA version is 4.4.4 running on Fedora 26

Is there something I may be overlooking here? I dove off into IPA v4
permissions and everything *seems* ok, but it is my chief suspect right now.

Thanks!

[Rob Crittenden]

Bob Rentschler via FreeIPA-users wrote:
>  This may be related to the issue discussed here: 
>
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>  
>  But it seems not to be, layer 8 is still open though.
>  
>  Using the instructions here
>
> https://www.dalemacartney.com/2013/03/14/deploying-postfix-with-ldap-free...
>  to enable postfix virtual users from freeIPA I seem to have hit a
>  sticking point in that postfix is unable to fetch the mail attribute.
>  
>  this is the query filter I modified as per the referenced email in the
>  archive.
>  
>  query_filter = (&(objectclass=posixaccount)(mail=%s))
>  
>  When run from postmap it gets nothing. If I change it for testing to
>  search by uid or another attribute it works as expected. a simple filter
>  like (uid=%s) works everytime.
>  
>  This ldapsearch run using the postfix servers keytab as credentials
>  works as well:
>  
>  ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=org
>  &#39;(&amp;(objectclass=posixaccount)(|(mail=validuser(a)example.org
>  <mailto:[e-mail]>)))'
>  
>  The FreeIPA version is 4.4.4 running on Fedora 26
>  
>  Is there something I may be overlooking here? I dove off into IPA v4
>  permissions and everything *seems* ok, but it is my chief suspect right now. 
When postmap gets nothing, is the LDAP query correct? What is the LDAP
error code?

The query you ran doesn't match the query_filter you posted. I mention
it in case this wasn't just a typo in the e-mail.

rob

[Bob Rentschler]

The query mismatch was a typo/mispaste, sorry about that.

It was indeed at least partly permissions in the LDAP server, likely
because a service is running the query.

I solved the freeipa permissions with the below command, which is likely
bad in some way but did allow postmap to return the
desired attributes:

ipa permission-mod "System: Read User Standard Attributes"
--includedattrs=mail --includedattrs=mailAlternateAddress

The attributes have been changed today, I am
using (|(mail=%s)(mailAlternateAddress=%s)) now that the simple (mail-%s)
works.

Is there a better or more proper way? That one seems to allow anonymous
enumeration of email accounts, which isn't a huge
problem for me, but I could see cases where it would be. It also seems a
waste to set up gssapi and TLS then weaken the LDAP
ACI's.

When I looked in the access log of the LDAP server I saw no error codes as
such, was /var/log/dirsrv/slapd-<domain>/access the wrong file to look in.

The remaining issue is posmap returns results just fine, but postfix itself
somehow fails to read the ldap alias map. I'll beat my
head on that for a few hours now.

For the interested the relevant section of main.cf is

virtual_alias_domains = domain.org
virtual_alias_maps = ldap:/etc/postfix/ldap_aliases.cf

All of the TLS functions are working properly, the directory server shows
this when postfix connects:


[03/Aug/2017:10:18:31.380423718 -0400] conn=95 op=0 SRCH
base="cn=users,cn=accounts,dc=domain,dc=ord" scope=2 filter="(|(mail=
[e-mail])(mailAlternateAddress=existing_user(a)domain.org))&quot;
attrs="uid"
[03/Aug/2017:10:18:31.381151196 -0400] conn=95 op=0 RESULT err=0 tag=101
nentries=1 etime=0

it also shows a few extras, I believe I need to tighetn up what postfix
looks for as these are queries related to the sending email account.

[03/Aug/2017:10:18:32.201190867 -0400] conn=96 op=1 SRCH
base="cn=users,cn=accounts,dc=domain,dc=org" scope=2
filter="(|(mail=<account test mail was sent
from>)(mailAlternateAddress=<account test mail was sent from>))"
attrs="uid"
[03/Aug/2017:10:18:32.201454459 -0400] conn=96 op=1 RESULT err=0 tag=101
nentries=0 etime=0
[03/Aug/2017:10:18:32.201883216 -0400] conn=96 op=2 SRCH
base="cn=users,cn=accounts,dc=notwise,dc=net" scope=2
filter="(|(mail=@<sending domain>)(mailAlternateAddress=@<sending
domain>))" attrs="uid"
[03/Aug/2017:10:18:32.202028213 -0400] conn=96 op=2 RESULT err=0 tag=101
nentries=0 etime=0

Thanks!
Bob

On Thu, Aug 3, 2017 at 10:06 AM, Rob Crittenden <rcritten(a)redhat.com&gt; wrote:

>  Bob Rentschler via FreeIPA-users wrote:
>  > This may be related to the issue discussed here:
>  > https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/
>  > <https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/&gt;
>  >
>  > But it seems not to be, layer 8 is still open though.
>  >
>  > Using the instructions here
>  > https://www.dalemacartney.com/2013/03/14/deploying-postfix-
>  with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/
>  > to enable postfix virtual users from freeIPA I seem to have hit a
>  > sticking point in that postfix is unable to fetch the mail attribute.
>  >
>  > this is the query filter I modified as per the referenced email in the
>  > archive.
>  >
>  > query_filter = (&(objectclass=posixaccount)(mail=%s))
>  >
>  > When run from postmap it gets nothing. If I change it for testing to
>  > search by uid or another attribute it works as expected. a simple filter
>  > like (uid=%s) works everytime.
>  >
>  > This ldapsearch run using the postfix servers keytab as credentials
>  > works as well:
>  >
>  > ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=org
>  > &#39;(&amp;(objectclass=posixaccount)(|(mail=validuser(a)example.org
>  > <mailto:[e-mail]>)))'
>  >
>  > The FreeIPA version is 4.4.4 running on Fedora 26
>  >
>  > Is there something I may be overlooking here? I dove off into IPA v4
>  > permissions and everything *seems* ok, but it is my chief suspect right
>  now.
>
>  When postmap gets nothing, is the LDAP query correct? What is the LDAP
>  error code?
>
>  The query you ran doesn't match the query_filter you posted. I mention
>  it in case this wasn't just a typo in the e-mail.
>
>  rob
>
>

[Rob Crittenden]

Bob Rentschler wrote:
>  The query mismatch was a typo/mispaste, sorry about that.
>  
>  It was indeed at least partly permissions in the LDAP server, likely
>  because a service is running the query.
>  
>  I solved the freeipa permissions with the below command, which is likely
>  bad in some way but did allow postmap to return the 
>  desired attributes:
>  
>  ipa permission-mod "System: Read User Standard Attributes"
>  --includedattrs=mail --includedattrs=mailAlternateAddress
>  
>  The attributes have been changed today, I am
>  using (|(mail=%s)(mailAlternateAddress=%s)) now that the simple
>  (mail-%s) works.
>  
>  Is there a better or more proper way? That one seems to allow anonymous
>  enumeration of email accounts, which isn't a huge
>  problem for me, but I could see cases where it would be. It also seems a
>  waste to set up gssapi and TLS then weaken the LDAP
>  ACI's. 
You could use "System: Read User Addressbook Attributes" instead which
requires an authenticated user.

>  
>  When I looked in the access log of the LDAP server I saw no error codes
>  as such, was /var/log/dirsrv/slapd-<domain>/access the wrong file to
>  look in. 
That's right but LDAP errors can be subtle.

>  The remaining issue is posmap returns results just fine, but postfix
>  itself somehow fails to read the ldap alias map. I'll beat my
>  head on that for a few hours now.
>  
>  For the interested the relevant section of main.cf <http://main.cf> is
>  
>  virtual_alias_domains = domain.org <http://domain.org>
>  virtual_alias_maps = ldap:/etc/postfix/ldap_aliases.cf
>  <http://ldap_aliases.cf>
>  
>  All of the TLS functions are working properly, the directory server
>  shows this when postfix connects:
>  
>  
>  [03/Aug/2017:10:18:31.380423718 -0400] conn=95 op=0 SRCH
>  base="cn=users,cn=accounts,dc=domain,dc=ord" scope=2
>  filter=&quot;(|(mail=existing_user(a)domain.org
>  <mailto:[e-mail]>)(mailAlternateAddress=[e-mail]
>  <mailto:[e-mail]>))" attrs="uid"
>  [03/Aug/2017:10:18:31.381151196 -0400] conn=95 op=0 RESULT err=0 tag=101
>  nentries=1 etime=0 
It is the err I was looking for. err=0 is good, though there are others
that can be acceptable as well depending on context. In this case one
user was found with the e-mail address.

>  it also shows a few extras, I believe I need to tighetn up what
> postfix
>  looks for as these are queries related to the sending email account.
>  
>  [03/Aug/2017:10:18:32.201190867 -0400] conn=96 op=1 SRCH
>  base="cn=users,cn=accounts,dc=domain,dc=org" scope=2
>  filter="(|(mail=<account test mail was sent
>  from>)(mailAlternateAddress=<account test mail was sent from>))"
> attrs="uid"
>  [03/Aug/2017:10:18:32.201454459 -0400] conn=96 op=1 RESULT err=0 tag=101
>  nentries=0 etime=0
>  [03/Aug/2017:10:18:32.201883216 -0400] conn=96 op=2 SRCH
>  base="cn=users,cn=accounts,dc=notwise,dc=net" scope=2
>  filter="(|(mail=@<sending domain>)(mailAlternateAddress=@<sending
>  domain>))" attrs="uid"
>  [03/Aug/2017:10:18:32.202028213 -0400] conn=96 op=2 RESULT err=0 tag=101
>  nentries=0 etime=0 
Hard to say without knowing your LDAP db but these could be perfectly
normal and expected. It is searching the right subtree and the query
format looks right, that's about all I can say :-)

rob

>  
>  Thanks!
>  Bob
>  
>  On Thu, Aug 3, 2017 at 10:06 AM, Rob Crittenden <rcritten(a)redhat.com
>  <mailto:[e-mail]>> wrote:
>  
>      Bob Rentschler via FreeIPA-users wrote:
>      > This may be related to the issue discussed here:
>      >
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>     
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>      >
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>     
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>      >
>      > But it seems not to be, layer 8 is still open though.
>      >
>      > Using the instructions here
>      >
> https://www.dalemacartney.com/2013/03/14/deploying-postfix-with-ldap-free...
>     
> <https://www.dalemacartney.com/2013/03/14/deploying-postfix-with-ldap-free...
>      > to enable postfix virtual users from freeIPA I seem to have hit a
>      > sticking point in that postfix is unable to fetch the mail attribute.
>      >
>      > this is the query filter I modified as per the referenced email in the
>      > archive.
>      >
>      > query_filter = (&(objectclass=posixaccount)(mail=%s))
>      >
>      > When run from postmap it gets nothing. If I change it for testing to
>      > search by uid or another attribute it works as expected. a simple filter
>      > like (uid=%s) works everytime.
>      >
>      > This ldapsearch run using the postfix servers keytab as credentials
>      > works as well:
>      >
>      > ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=org
>      > &#39;(&amp;(objectclass=posixaccount)(|(mail=validuser(a)example.org
> <mailto:[e-mail]>
>      > <mailto:[e-mail]
> <mailto:[e-mail]>>)))'
>      >
>      > The FreeIPA version is 4.4.4 running on Fedora 26
>      >
>      > Is there something I may be overlooking here? I dove off into IPA v4
>      > permissions and everything *seems* ok, but it is my chief suspect right now.
>  
>      When postmap gets nothing, is the LDAP query correct? What is the LDAP
>      error code?
>  
>      The query you ran doesn't match the query_filter you posted. I mention
>      it in case this wasn't just a typo in the e-mail.
>  
>      rob
>  
>

[Bob Rentschler]

It seems the postfix problem was of my creation, I reset the postfix config
file to a copy of the default, re-did everything a step at
a time and it all worked. Who knows what I had in there screwing it up, I
still can't find it when I compare them.

To sum it up under ipa v4 you need to in one way or another make sure the
mail attributes(s) can be read.

Perhaps this is a candidate for a new default permission/privilege/role for
services feature request?

Bob

On Thu, Aug 3, 2017 at 10:42 AM, Rob Crittenden <rcritten(a)redhat.com&gt; wrote:

>  Bob Rentschler wrote:
>  > The query mismatch was a typo/mispaste, sorry about that.
>  >
>  > It was indeed at least partly permissions in the LDAP server, likely
>  > because a service is running the query.
>  >
>  > I solved the freeipa permissions with the below command, which is likely
>  > bad in some way but did allow postmap to return the
>  > desired attributes:
>  >
>  > ipa permission-mod "System: Read User Standard Attributes"
>  > --includedattrs=mail --includedattrs=mailAlternateAddress
>  >
>  > The attributes have been changed today, I am
>  > using (|(mail=%s)(mailAlternateAddress=%s)) now that the simple
>  > (mail-%s) works.
>  >
>  > Is there a better or more proper way? That one seems to allow anonymous
>  > enumeration of email accounts, which isn't a huge
>  > problem for me, but I could see cases where it would be. It also seems a
>  > waste to set up gssapi and TLS then weaken the LDAP
>  > ACI's.
>
>  You could use "System: Read User Addressbook Attributes" instead which
>  requires an authenticated user.
>
>  >
>  > When I looked in the access log of the LDAP server I saw no error codes
>  > as such, was /var/log/dirsrv/slapd-<domain>/access the wrong file to
>  > look in.
>
>  That's right but LDAP errors can be subtle.
>
>  > The remaining issue is posmap returns results just fine, but postfix
>  > itself somehow fails to read the ldap alias map. I'll beat my
>  > head on that for a few hours now.
>  >
>  > For the interested the relevant section of main.cf <http://main.cf> is
>  >
>  > virtual_alias_domains = domain.org <http://domain.org>
>  > virtual_alias_maps = ldap:/etc/postfix/ldap_aliases.cf
>  > <http://ldap_aliases.cf>
>  >
>  > All of the TLS functions are working properly, the directory server
>  > shows this when postfix connects:
>  >
>  >
>  > [03/Aug/2017:10:18:31.380423718 -0400] conn=95 op=0 SRCH
>  > base="cn=users,cn=accounts,dc=domain,dc=ord" scope=2
>  > filter=&quot;(|(mail=existing_user(a)domain.org
>  > <mailto:[e-mail]>)(mailAlternateAddress=exi
>  sting_user(a)domain.org
>  > <mailto:[e-mail]>))" attrs="uid"
>  > [03/Aug/2017:10:18:31.381151196 -0400] conn=95 op=0 RESULT err=0 tag=101
>  > nentries=1 etime=0
>
>  It is the err I was looking for. err=0 is good, though there are others
>  that can be acceptable as well depending on context. In this case one
>  user was found with the e-mail address.
>
>  > it also shows a few extras, I believe I need to tighetn up what postfix
>  > looks for as these are queries related to the sending email account.
>  >
>  > [03/Aug/2017:10:18:32.201190867 -0400] conn=96 op=1 SRCH
>  > base="cn=users,cn=accounts,dc=domain,dc=org" scope=2
>  > filter="(|(mail=<account test mail was sent
>  > from>)(mailAlternateAddress=<account test mail was sent from>))"
>  attrs="uid"
>  > [03/Aug/2017:10:18:32.201454459 -0400] conn=96 op=1 RESULT err=0 tag=101
>  > nentries=0 etime=0
>  > [03/Aug/2017:10:18:32.201883216 -0400] conn=96 op=2 SRCH
>  > base="cn=users,cn=accounts,dc=notwise,dc=net" scope=2
>  > filter="(|(mail=@<sending domain>)(mailAlternateAddress=@<sending
>  > domain>))" attrs="uid"
>  > [03/Aug/2017:10:18:32.202028213 -0400] conn=96 op=2 RESULT err=0 tag=101
>  > nentries=0 etime=0
>
>  Hard to say without knowing your LDAP db but these could be perfectly
>  normal and expected. It is searching the right subtree and the query
>  format looks right, that's about all I can say :-)
>
>  rob
>
>  >
>  > Thanks!
>  > Bob
>  >
>  > On Thu, Aug 3, 2017 at 10:06 AM, Rob Crittenden <rcritten(a)redhat.com
>  > <mailto:[e-mail]>> wrote:
>  >
>  >     Bob Rentschler via FreeIPA-users wrote:
>  >     > This may be related to the issue discussed here:
>  >     > https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/
>  >     <https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/&gt;
>  >     > <https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/
>  >     <https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/&gt;&gt;
>  >     >
>  >     > But it seems not to be, layer 8 is still open though.
>  >     >
>  >     > Using the instructions here
>  >     > https://www.dalemacartney.com/2013/03/14/deploying-postfix-
>  with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/
>  >     <https://www.dalemacartney.com/2013/03/14/deploying-
>  postfix-with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/>
>  >     > to enable postfix virtual users from freeIPA I seem to have hit a
>  >     > sticking point in that postfix is unable to fetch the mail
>  attribute.
>  >     >
>  >     > this is the query filter I modified as per the referenced email in
>  the
>  >     > archive.
>  >     >
>  >     > query_filter = (&(objectclass=posixaccount)(mail=%s))
>  >     >
>  >     > When run from postmap it gets nothing. If I change it for testing
>  to
>  >     > search by uid or another attribute it works as expected. a simple
>  filter
>  >     > like (uid=%s) works everytime.
>  >     >
>  >     > This ldapsearch run using the postfix servers keytab as credentials
>  >     > works as well:
>  >     >
>  >     > ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=
>  example,dc=org
>  >     > &#39;(&amp;(objectclass=posixaccount)(|(mail=validuser(a)example.org
>  <mailto:[e-mail]>
>  >     > <mailto:[e-mail]
> <mailto:[e-mail]>>)))'
>  >     >
>  >     > The FreeIPA version is 4.4.4 running on Fedora 26
>  >     >
>  >     > Is there something I may be overlooking here? I dove off into IPA
>  v4
>  >     > permissions and everything *seems* ok, but it is my chief suspect
>  right now.
>  >
>  >     When postmap gets nothing, is the LDAP query correct? What is the
>  LDAP
>  >     error code?
>  >
>  >     The query you ran doesn't match the query_filter you posted. I
>  mention
>  >     it in case this wasn't just a typo in the e-mail.
>  >
>  >     rob
>  >
>  >
>
>

[Rob Crittenden]

Bob Rentschler wrote:
>  It seems the postfix problem was of my creation, I reset the postfix
>  config file to a copy of the default, re-did everything a step at
>  a time and it all worked. Who knows what I had in there screwing it up,
>  I still can't find it when I compare them.
>  
>  To sum it up under ipa v4 you need to in one way or another make sure
>  the mail attributes(s) can be read. 
>  
>  Perhaps this is a candidate for a new default permission/privilege/role
>  for services feature request? 
The team has had many discussions on how to make customizations easier
and more plugable. This is one of the scenarios that has been discussed:
making an existing attribute that IPA doesn't normally support available.

The idea being you could install freeipa-plugin-postfix and it would
have everything needed to enable it (in this case just a few ACI changes).

So yeah, I'm for it, but this would potentially be blazing some new
ground. There is also the issue that service users (e.g. LDAP-only)
can't easily be assigned to ACIs.

rob

>  
>  Bob
>  
>  On Thu, Aug 3, 2017 at 10:42 AM, Rob Crittenden <rcritten(a)redhat.com
>  <mailto:[e-mail]>> wrote:
>  
>      Bob Rentschler wrote:
>      > The query mismatch was a typo/mispaste, sorry about that.
>      >
>      > It was indeed at least partly permissions in the LDAP server, likely
>      > because a service is running the query.
>      >
>      > I solved the freeipa permissions with the below command, which is likely
>      > bad in some way but did allow postmap to return the
>      > desired attributes:
>      >
>      > ipa permission-mod "System: Read User Standard Attributes"
>      > --includedattrs=mail --includedattrs=mailAlternateAddress
>      >
>      > The attributes have been changed today, I am
>      > using (|(mail=%s)(mailAlternateAddress=%s)) now that the simple
>      > (mail-%s) works.
>      >
>      > Is there a better or more proper way? That one seems to allow anonymous
>      > enumeration of email accounts, which isn't a huge
>      > problem for me, but I could see cases where it would be. It also seems a
>      > waste to set up gssapi and TLS then weaken the LDAP
>      > ACI's.
>  
>      You could use "System: Read User Addressbook Attributes" instead which
>      requires an authenticated user.
>  
>      >
>      > When I looked in the access log of the LDAP server I saw no error codes
>      > as such, was /var/log/dirsrv/slapd-<domain>/access the wrong file to
>      > look in.
>  
>      That's right but LDAP errors can be subtle.
>  
>      > The remaining issue is posmap returns results just fine, but postfix
>      > itself somehow fails to read the ldap alias map. I'll beat my
>      > head on that for a few hours now.
>      >
>      > For the interested the relevant section of main.cf
>      <http://main.cf> <http://main.cf> is
>      >
>      > virtual_alias_domains = domain.org <http://domain.org>
>      <http://domain.org>
>      > virtual_alias_maps = ldap:/etc/postfix/ldap_aliases.cf
>      <http://ldap_aliases.cf>
>      > <http://ldap_aliases.cf>
>      >
>      > All of the TLS functions are working properly, the directory server
>      > shows this when postfix connects:
>      >
>      >
>      > [03/Aug/2017:10:18:31.380423718 -0400] conn=95 op=0 SRCH
>      > base="cn=users,cn=accounts,dc=domain,dc=ord" scope=2
>      > filter=&quot;(|(mail=existing_user(a)domain.org
> <mailto:[e-mail]>
>      > <mailto:[e-mail]
>     
> <mailto:[e-mail]>>)(mailAlternateAddress=[e-mail]
>      <mailto:[e-mail]>
>      > <mailto:[e-mail]
>      <mailto:[e-mail]>>))" attrs="uid"
>      > [03/Aug/2017:10:18:31.381151196 -0400] conn=95 op=0 RESULT err=0 tag=101
>      > nentries=1 etime=0
>  
>      It is the err I was looking for. err=0 is good, though there are others
>      that can be acceptable as well depending on context. In this case one
>      user was found with the e-mail address.
>  
>      > it also shows a few extras, I believe I need to tighetn up what postfix
>      > looks for as these are queries related to the sending email account.
>      >
>      > [03/Aug/2017:10:18:32.201190867 -0400] conn=96 op=1 SRCH
>      > base="cn=users,cn=accounts,dc=domain,dc=org" scope=2
>      > filter="(|(mail=<account test mail was sent
>      > from>)(mailAlternateAddress=<account test mail was sent from>))"
> attrs="uid"
>      > [03/Aug/2017:10:18:32.201454459 -0400] conn=96 op=1 RESULT err=0 tag=101
>      > nentries=0 etime=0
>      > [03/Aug/2017:10:18:32.201883216 -0400] conn=96 op=2 SRCH
>      > base="cn=users,cn=accounts,dc=notwise,dc=net" scope=2
>      > filter="(|(mail=@<sending domain>)(mailAlternateAddress=@<sending
>      > domain>))" attrs="uid"
>      > [03/Aug/2017:10:18:32.202028213 -0400] conn=96 op=2 RESULT err=0 tag=101
>      > nentries=0 etime=0
>  
>      Hard to say without knowing your LDAP db but these could be perfectly
>      normal and expected. It is searching the right subtree and the query
>      format looks right, that's about all I can say :-)
>  
>      rob
>  
>      >
>      > Thanks!
>      > Bob
>      >
>      > On Thu, Aug 3, 2017 at 10:06 AM, Rob Crittenden <rcritten(a)redhat.com
> <mailto:[e-mail]>
>      > <mailto:[e-mail] <mailto:[e-mail]>>>
> wrote:
>      >
>      >     Bob Rentschler via FreeIPA-users wrote:
>      >     > This may be related to the issue discussed here:
>      >     >
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>     
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>      >    
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>     
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>      >     >
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>     
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>      >    
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>     
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>      >     >
>      >     > But it seems not to be, layer 8 is still open though.
>      >     >
>      >     > Using the instructions here
>      >     >
> https://www.dalemacartney.com/2013/03/14/deploying-postfix-with-ldap-free...
>     
> <https://www.dalemacartney.com/2013/03/14/deploying-postfix-with-ldap-free...
>      >    
> <https://www.dalemacartney.com/2013/03/14/deploying-postfix-with-ldap-free...
>     
> <https://www.dalemacartney.com/2013/03/14/deploying-postfix-with-ldap-free...
>      >     > to enable postfix virtual users from freeIPA I seem to have hit a
>      >     > sticking point in that postfix is unable to fetch the mail attribute.
>      >     >
>      >     > this is the query filter I modified as per the referenced email in the
>      >     > archive.
>      >     >
>      >     > query_filter = (&(objectclass=posixaccount)(mail=%s))
>      >     >
>      >     > When run from postmap it gets nothing. If I change it for testing to
>      >     > search by uid or another attribute it works as expected. a simple
> filter
>      >     > like (uid=%s) works everytime.
>      >     >
>      >     > This ldapsearch run using the postfix servers keytab as credentials
>      >     > works as well:
>      >     >
>      >     > ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=org
>      >     > &#39;(&amp;(objectclass=posixaccount)(|(mail=validuser(a)example.org
> <mailto:[e-mail]>
>      <mailto:[e-mail] <mailto:[e-mail]>>
>      >     > <mailto:[e-mail] <mailto:[e-mail]>
>      <mailto:[e-mail]
> <mailto:[e-mail]>>>)))'
>      >     >
>      >     > The FreeIPA version is 4.4.4 running on Fedora 26
>      >     >
>      >     > Is there something I may be overlooking here? I dove off
>      into IPA v4
>      >     > permissions and everything *seems* ok, but it is my chief
>      suspect right now.
>      >
>      >     When postmap gets nothing, is the LDAP query correct? What is
>      the LDAP
>      >     error code?
>      >
>      >     The query you ran doesn't match the query_filter you posted. I
>      mention
>      >     it in case this wasn't just a typo in the e-mail.
>      >
>      >     rob
>      >
>      >
>  
>

[Bob Rentschler]

Something like that would be quite welcome, I'd love to use IPA to replace
our current 3! "SSO" LDAP
environments. They do all work together with lots of duct tape and glue but
a clean solution would
be great.



On Thu, Aug 3, 2017 at 2:27 PM, Rob Crittenden <rcritten(a)redhat.com&gt; wrote:

>  Bob Rentschler wrote:
>  > It seems the postfix problem was of my creation, I reset the postfix
>  > config file to a copy of the default, re-did everything a step at
>  > a time and it all worked. Who knows what I had in there screwing it up,
>  > I still can't find it when I compare them.
>  >
>  > To sum it up under ipa v4 you need to in one way or another make sure
>  > the mail attributes(s) can be read.
>  >
>  > Perhaps this is a candidate for a new default permission/privilege/role
>  > for services feature request?
>
>  The team has had many discussions on how to make customizations easier
>  and more plugable. This is one of the scenarios that has been discussed:
>  making an existing attribute that IPA doesn't normally support available.
>
>  The idea being you could install freeipa-plugin-postfix and it would
>  have everything needed to enable it (in this case just a few ACI changes).
>
>  So yeah, I'm for it, but this would potentially be blazing some new
>  ground. There is also the issue that service users (e.g. LDAP-only)
>  can't easily be assigned to ACIs.
>
>  rob
>
>  >
>  > Bob
>  >
>  > On Thu, Aug 3, 2017 at 10:42 AM, Rob Crittenden <rcritten(a)redhat.com
>  > <mailto:[e-mail]>> wrote:
>  >
>  >     Bob Rentschler wrote:
>  >     > The query mismatch was a typo/mispaste, sorry about that.
>  >     >
>  >     > It was indeed at least partly permissions in the LDAP server,
>  likely
>  >     > because a service is running the query.
>  >     >
>  >     > I solved the freeipa permissions with the below command, which is
>  likely
>  >     > bad in some way but did allow postmap to return the
>  >     > desired attributes:
>  >     >
>  >     > ipa permission-mod "System: Read User Standard Attributes"
>  >     > --includedattrs=mail --includedattrs=mailAlternateAddress
>  >     >
>  >     > The attributes have been changed today, I am
>  >     > using (|(mail=%s)(mailAlternateAddress=%s)) now that the simple
>  >     > (mail-%s) works.
>  >     >
>  >     > Is there a better or more proper way? That one seems to allow
>  anonymous
>  >     > enumeration of email accounts, which isn't a huge
>  >     > problem for me, but I could see cases where it would be. It also
>  seems a
>  >     > waste to set up gssapi and TLS then weaken the LDAP
>  >     > ACI's.
>  >
>  >     You could use "System: Read User Addressbook Attributes" instead
>  which
>  >     requires an authenticated user.
>  >
>  >     >
>  >     > When I looked in the access log of the LDAP server I saw no error
>  codes
>  >     > as such, was /var/log/dirsrv/slapd-<domain>/access the wrong file
>  to
>  >     > look in.
>  >
>  >     That's right but LDAP errors can be subtle.
>  >
>  >     > The remaining issue is posmap returns results just fine, but
>  postfix
>  >     > itself somehow fails to read the ldap alias map. I'll beat my
>  >     > head on that for a few hours now.
>  >     >
>  >     > For the interested the relevant section of main.cf
>  >     <http://main.cf> <http://main.cf> is
>  >     >
>  >     > virtual_alias_domains = domain.org <http://domain.org>
>  >     <http://domain.org>
>  >     > virtual_alias_maps = ldap:/etc/postfix/ldap_aliases.cf
>  >     <http://ldap_aliases.cf>
>  >     > <http://ldap_aliases.cf>
>  >     >
>  >     > All of the TLS functions are working properly, the directory server
>  >     > shows this when postfix connects:
>  >     >
>  >     >
>  >     > [03/Aug/2017:10:18:31.380423718 -0400] conn=95 op=0 SRCH
>  >     > base="cn=users,cn=accounts,dc=domain,dc=ord" scope=2
>  >     > filter=&quot;(|(mail=existing_user(a)domain.org <mailto:
>  existing_user(a)domain.org&gt;
>  >     > <mailto:[e-mail]
>  >     <mailto:[e-mail]>>)(mailAlternateAddress=ex
>  isting_user(a)domain.org
>  >     <mailto:[e-mail]>
>  >     > <mailto:[e-mail]
>  >     <mailto:[e-mail]>>))" attrs="uid"
>  >     > [03/Aug/2017:10:18:31.381151196 -0400] conn=95 op=0 RESULT err=0
>  tag=101
>  >     > nentries=1 etime=0
>  >
>  >     It is the err I was looking for. err=0 is good, though there are
>  others
>  >     that can be acceptable as well depending on context. In this case one
>  >     user was found with the e-mail address.
>  >
>  >     > it also shows a few extras, I believe I need to tighetn up what
>  postfix
>  >     > looks for as these are queries related to the sending email
>  account.
>  >     >
>  >     > [03/Aug/2017:10:18:32.201190867 -0400] conn=96 op=1 SRCH
>  >     > base="cn=users,cn=accounts,dc=domain,dc=org" scope=2
>  >     > filter="(|(mail=<account test mail was sent
>  >     > from>)(mailAlternateAddress=<account test mail was sent
> from>))"
>  attrs="uid"
>  >     > [03/Aug/2017:10:18:32.201454459 -0400] conn=96 op=1 RESULT err=0
>  tag=101
>  >     > nentries=0 etime=0
>  >     > [03/Aug/2017:10:18:32.201883216 -0400] conn=96 op=2 SRCH
>  >     > base="cn=users,cn=accounts,dc=notwise,dc=net" scope=2
>  >     > filter="(|(mail=@<sending
> domain>)(mailAlternateAddress=@<sending
>  >     > domain>))" attrs="uid"
>  >     > [03/Aug/2017:10:18:32.202028213 -0400] conn=96 op=2 RESULT err=0
>  tag=101
>  >     > nentries=0 etime=0
>  >
>  >     Hard to say without knowing your LDAP db but these could be perfectly
>  >     normal and expected. It is searching the right subtree and the query
>  >     format looks right, that's about all I can say :-)
>  >
>  >     rob
>  >
>  >     >
>  >     > Thanks!
>  >     > Bob
>  >     >
>  >     > On Thu, Aug 3, 2017 at 10:06 AM, Rob Crittenden <
>  rcritten(a)redhat.com <mailto:[e-mail]>
>  >     > <mailto:[e-mail] <mailto:[e-mail]>>>
> wrote:
>  >     >
>  >     >     Bob Rentschler via FreeIPA-users wrote:
>  >     >     > This may be related to the issue discussed here:
>  >     >     > https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/
>  >     <https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/&gt;
>  >     >     <https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/
>  >     <https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/&gt;&gt;
>  >     >     > <https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/
>  >     <https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/&gt;
>  >     >     <https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/
>  >     <https://lists.fedorahosted.org/archives/list/freeipa-
>  users(a)lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/&gt;&gt;&gt;
>  >     >     >
>  >     >     > But it seems not to be, layer 8 is still open though.
>  >     >     >
>  >     >     > Using the instructions here
>  >     >     > https://www.dalemacartney.com/2013/03/14/deploying-postfix-
>  with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/
>  >     <https://www.dalemacartney.com/2013/03/14/deploying-
>  postfix-with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/>
>  >     >     <https://www.dalemacartney.com/2013/03/14/deploying-
>  postfix-with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/
>  >     <https://www.dalemacartney.com/2013/03/14/deploying-
>  postfix-with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/>>
>  >     >     > to enable postfix virtual users from freeIPA I seem to have
>  hit a
>  >     >     > sticking point in that postfix is unable to fetch the mail
>  attribute.
>  >     >     >
>  >     >     > this is the query filter I modified as per the referenced
>  email in the
>  >     >     > archive.
>  >     >     >
>  >     >     > query_filter = (&(objectclass=posixaccount)(mail=%s))
>  >     >     >
>  >     >     > When run from postmap it gets nothing. If I change it for
>  testing to
>  >     >     > search by uid or another attribute it works as expected. a
>  simple filter
>  >     >     > like (uid=%s) works everytime.
>  >     >     >
>  >     >     > This ldapsearch run using the postfix servers keytab as
>  credentials
>  >     >     > works as well:
>  >     >     >
>  >     >     > ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=
>  example,dc=org
>  >     >     >
> &#39;(&amp;(objectclass=posixaccount)(|(mail=validuser(a)example.org
>  <mailto:[e-mail]>
>  >     <mailto:[e-mail] <mailto:[e-mail]>>
>  >     >     > <mailto:[e-mail]
> <mailto:[e-mail]>
>  >     <mailto:[e-mail]
> <mailto:[e-mail]>>>)))'
>  >     >     >
>  >     >     > The FreeIPA version is 4.4.4 running on Fedora 26
>  >     >     >
>  >     >     > Is there something I may be overlooking here? I dove off
>  >     into IPA v4
>  >     >     > permissions and everything *seems* ok, but it is my chief
>  >     suspect right now.
>  >     >
>  >     >     When postmap gets nothing, is the LDAP query correct? What is
>  >     the LDAP
>  >     >     error code?
>  >     >
>  >     >     The query you ran doesn't match the query_filter you posted. I
>  >     mention
>  >     >     it in case this wasn't just a typo in the e-mail.
>  >     >
>  >     >     rob
>  >     >
>  >     >
>  >
>  >
>
>

[Christian Glombek]

I can only second that. Official FreeIPA plugins for Postfix and Dovecot would be
immensely helpful.
 
Someone made a plugin that adds mailAlternateAdress to the scheme and ui, which is
somewhat related to this issue:
https://github.com/pdf/freeipa-user-mailalternateaddress

[Rob Crittenden]

Christian Glombek via FreeIPA-users wrote:
>  I can only second that. Official FreeIPA plugins for Postfix and
> Dovecot would be immensely helpful.
>   
>  Someone made a plugin that adds mailAlternateAdress to the scheme and ui, which is
> somewhat related to this issue:
>  https://github.com/pdf/freeipa-user-mailalternateaddress 
To be clear, my proposal was for someone outside the IPA team to do the
packaging and we would provide assistance.

rob

[Christian Glombek]

Ok fair enough, I'd like to help with that.

So before I write up an rpm spec for freeipa-plugin-postfix, could you summarize what
would go in there?

On the freeipa server, you'll still have to manually create a service principle for
your postfix server, right?

Also what is the recommended way for a service to connect? I'm also using the SSO LDAP
way mentioned earlier, but are there any viable alternatives?

Thanks
Chris