Sorry guys, but whatever rules you may adopt to name an AD domain (that is not the topic of this request) it doesn’t help to solve the issue.
The problem is that nethserver 7 doesn’t read anymore AD to determine the user’s email address.
1 Like
So, let’s open a new topic in the Feature category! We’ve seen here why this is not the way ns7 works but we can discuss how to implement a new solution.
So let’s start …
The point is, users and resources should be centrally managed by a directory service … in this case Microsoft AD. It can’t be NS just because it doesn’t have all the tools needed to do the job.
Being things as is will compell in the best case to stay on 6.8 or worst to abandon NS at all, at least for email services.
As said in the past, the upstream Postfix package comes with no support for Kerberos. Without KB support, we can’t browse the AD LDAP and configure it as Postfix DB for address alias expansion.
So I see two possible ways to implement this feature:
- run a cronjob that once per hour
* authenticates by system keytab on AD LDAP (maintained by realmd, I suppose)
* fetches all mail aliases
* removes old aliases in esmith DB
* pushes new aliases into esmith accounts DB as pseudonym records
* expands ``/etc/postfix/virtual`` template and updates the Postfix DB
- write down a service daemon that
- authenticates by system keytab
- translates DB queries from postfix DB to AD according to the tcp_table specification
Both solutions have pros and cons:
-
is simple and robust but email addresses are updated periodically; the server-manager interface cannot be used to manage mail aliases because they are overwritten by the cronjob. The logic can be improved to handle merges nicely, instead of destroy the DB on each round, and also display imported aliases as “gray/disabled” in server-manager, but we lose simplicity.
-
is elegant, but complex and more difficult to program; however it allows to fine-tune a local cache of mail addresses, to support AD service outages. The server-manager is not aware of mail aliases from AD at all.
Both solutions can start small and be improved at a later stage.
Please contribute with more solutions or by refining existing ones!
3 Likes
[quote=“davidep, post:4, topic:4764, full:true”]
As said in the past, the upstream Postfix package comes with no support for Kerberos. Without KB support, we can’t browse the AD LDAP and configure it as Postfix DB for address alias expansion.[/quote]
I’m discovering this topic and, again, as I’ve not yet 
installed NS, my comment might be just a stupid one…
I don’t really understand what you describe here, or, rather, I may understand but, in such case, this sounds strange to me.
Do you mean to say that S4-LDAP doesn’t accept either anonymous or simple bind but only SASL bind (which through GSSAPI, means KRB) ?
I know I need to deploy NS, I’ll do it…
FYI, having deployed UCS for some customers (NS was not yet in my scope because Rob was late 
), I can access its S4-LDAP server authenticating either with SASL or simple bind and even anonymously. Then one could discuss whether anonymous access is a good idea or not (I think it is but requires some ACL) bt from pure technical view point, this is achievable.
3 Likes
WOAHH @Christian… so now that’s MY fault for you not being aware of Nethserver before… LMAO now THAT is funny… 
I hope no one doubt this is a joke.
The easiest way for me to explain that I gave a try to UCS because I was not aware or forgot that Netserver existed.
And also a way to make clear that I’m looking at Nethserver because you notified me. A bit late indeed, but you can’t be really faulty for this, can you? 
Ouch, your antenna for jokes is failing… lol…
And again, great to have you here… 
This is the point. We try to lower the requirements on NS side as much as possible to ease the integration with existing Active Directory environments, where doing any kind of security policy change is an issue! That means, no custom ACLs for anonymous binds, and no SSL certificates installation to protect clear text protocols.
In this scenario, on the ns6 Postfix side, the GSSAPI auth-binds seemed the only possible way. It leaded to other kind of issues, for instance the Kerberos tickets renewal, that is somewhat complex to deal with.
However on ns7 we have our hands free to design a new solution for those who want to read email addresses from AD.
Anonymous bind could be an interesting option for those who can adopt it, but cannot be the default. Just to have an idea, do you have any pointer to a good guide for the windows administrator that explains how to configure the AD side for anonymous binds?
What are we speaking about? Is it “AD” (I mean Active Directory from Microsoft) of “AD-Samba”?
I’d say both of them
Yes both implementations are interesting, anyway I meant MS-AD. Hopefully the Samba AD should be configured in the same way…
windows administrator is for MS-AD!
Looking at Microsoft documentation, anonymous access is achieved modifying dsHeuristics attribute.
Looking at Samba 4 wiki, it states that same attribute can be used the same way (indeed Samba 4 directory does mimic closely AD, with all the pros & cons 
)
[quote]Does the Samba Internal LDAP Server Supports Anonymous Searches?
Samba honours the dSHeuristics flag. For details, see http://support.microsoft.com/kb/326690
However, enabling anonymous access to the AD raises security
problems and is not recommended. Configure LDAP authentication or
Kerberos support in your client instead.
[/quote]
This said, obviously they do not recommend anonymous access because this LDAP back-end is not expected to be used as LDAP back-end for external application and server not having at least joined AD domain.
1 Like