The data staysin the building.So does the signature.
Name, job title, department and phone number live in Active Directory. To get them into every signature, most vendors require a directory sync into the cloud. Conbool does not: an agent on a member server reads the directory and reports people outbound. No Entra ID, no inbound firewall rule.
Why signatures fail at the directory
Four points where it stalls in practice.
No Entra ID, yet still a prerequisite
Anyone running mailboxes on site, or deliberately keeping their directory away from the Microsoft cloud, finds the same sentence in almost every data sheet: people data comes from Entra ID. A directory sync thereby becomes the condition for having a signature.
A path from outside into the directory
The alternative is access from outside to the domain controller, through a firewall rule or a published LDAP endpoint. That is the path nobody wants, and the one that never has a good justification in an audit.
Transport rules know no attributes
A rule in Exchange appends fixed text. It inserts no job title, no department and no phone number, it lands below quoted replies, and with several languages and exceptions the rule set becomes unmanageable.
Everything is maintained twice
Where the signature keeps its own list of people, the two drift apart. A change of department is in the directory, the signature still shows the old one, and the recipient notices first.
How the route works instead
Three steps, after which the directory maintains the signature.
1. An agent on a member server
The directory agent runs as a service on an ordinary member server of the domain, not on the domain controller. It authenticates with the account it runs under, and no password is stored anywhere.
2. Outbound only, never inbound
The agent calls Conbool, Conbool never calls the agent. Nothing is exposed: no inbound firewall rule, no published domain controller, no path from outside into the directory.
3. Signature at the gateway
Outbound messages travel through the gateway, where the signature is created server side with that person's fields. Identical on every device, without installing anything on a client, without touching the MX record.
What sets this route apart
Six points that matter day to day.
Fourteen fields per person
Display name, first name, surname, job title, department, phone, mobile, office, street, city, state, postal code, country and fax, plus secondary addresses and the state of the account. Which attribute fills which field can be changed per field.
Without the right to password data
Reading uses ordinary read access. Incremental sync adds two rights at the domain head. The right that would allow password data to be read from the directory is explicitly not among them and is never requested.
Secondary addresses count as the same person
Further addresses come along as aliases. They decide whether a message sent under a secondary address gets its signature, and they prevent one human being counted as two seats.
Groups with their nesting
Directory groups serve as the audience for templates and policies. Nested groups are resolved in full, so a group with three entries can yield seven people.
A dry run before anything is written
After every change to the scope the agent runs dry and shows how many people would be created, changed or removed. If more than ten percent would disappear, it holds the run and writes nothing.
For LDAP and for your own server room
The same agent reads OpenLDAP and related directories. And where processing has to stay in house, Conbool runs as an installation in your own data centre, keeping the entire chain under your control.
Two routes to the same fields
Directory sync into the cloud, or an outbound agent.
With Conbool | The usual cloud route | |
|---|---|---|
| Entra ID required | no | yes, including directory sync |
| Inbound access into the directory | none | none, but the sync instead |
| Local directory attributes in the signature | yes, directly | only after the sync |
| Other LDAP directories | yes | rarely |
| Operation in your own data centre | possible | no |
Statements about the usual route follow the publicly documented prerequisites of common signature services that source people data from Entra ID.
Frequently asked questions
Is Entra ID required for signatures from Active Directory?
Which rights does the agent need in the directory?
Does a firewall port have to be opened?
Where does the agent run?
What happens if the scope is set wrongly?
Does this work with OpenLDAP?
Does the MX record have to change?
Related solutions
Exclaimer-Alternative
Layered-Disclaimer aus der EU, ohne UK-PE-Mutter und Per-User-Bundle.
Zentrale E-Mail Signatur
Server-seitige Signaturen, einheitlich auf allen Geräten und Clients.
E-Mail Signatur Management
Unternehmensweite Signaturen zentral verwalten und ausrollen.
E-Mail Disclaimer
Pflichtangaben automatisiert, rechtssicher und compliance-konform.
See it against your own directory
We set the agent up in a test environment and show the first dry run with real people, before anything is written.