Re: IETF opinion change on "implicit TLS" vs. StartTLS

2018-02-12 Thread Quanah Gibson-Mount
--On Tuesday, February 13, 2018 9:31 AM +1000 William Brown 
 wrote:



On Mon, 2018-02-12 at 14:30 +0100, Michael Ströder wrote:

HI!

To me this rationale for SMTP submission with implicit TLS seems also
applicable to LDAPS vs. StartTLS:

https://tools.ietf.org/html/rfc8314#appendix-A

So LDAPS should not be considered deprecated. Rather it should be
recommended and the _optional_ use of StartTLS should be strongly
discouraged.


Yes, I strongly agree with this. I have evidence to this fact and can
provide it if required,


Personally, I'm all for it.  I'd suggest using the above RFC as a template 
for one formalizing port 636, so it's finally a documented standard.


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:





Re: IETF opinion change on "implicit TLS" vs. StartTLS

2018-02-12 Thread William Brown
On Mon, 2018-02-12 at 14:30 +0100, Michael Ströder wrote:
> HI!
> 
> To me this rationale for SMTP submission with implicit TLS seems also
> applicable to LDAPS vs. StartTLS:
> 
> https://tools.ietf.org/html/rfc8314#appendix-A
> 
> So LDAPS should not be considered deprecated. Rather it should be
> recommended and the _optional_ use of StartTLS should be strongly
> discouraged.

Yes, I strongly agree with this. I have evidence to this fact and can
provide it if required,



> 
> Ciao, Michael.
> 
-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane




dynamic config replication

2018-02-12 Thread Gerard Ranke
Hello list,

Openldap 2.4.45 here, on 1 producer and 4 consumers. ( I'll attach
relevant parts of the configuration at the end of this message. )
Following the scripts from test059, I configured the producer to serve
up a cn=config backend for the consumers. This seems to work nicely at
first: When you start a consumer from a minimal config, it loads the
producers schemafiles and the cn=config, and replication of the main
database is fine. Also, when fi. changing the loglevel on the producers
cn=config,cn=slave, the consumers pick up this change in their cn=config.
However, when I modify an olcAccess line on the producers
cn=config,cn=slave database, I get these errors on the consumer:

slapd[26324]: syncrepl_message_to_entry: rid=002 DN:
olcDatabase={1}mdb,cn=config,cn=slave, UUID:
7cff5ef6-90b1-1037-9d95-6dfd3149c2dc
slapd[26324]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
slapd[26324]: syncrepl_entry: rid=002 inserted UUID
7cff5ef6-90b1-1037-9d95-6dfd3149c2dc
slapd[26324]: syncrepl_entry: rid=002 be_search (0)
slapd[26324]: syncrepl_entry: rid=002 olcDatabase={1}mdb,cn=config
slapd[26324]: null_callback : error code 0x43
slapd[26324]: syncrepl_entry: rid=002 be_modify
olcDatabase={1}mdb,cn=config (67)
slapd[26324]: syncrepl_entry: rid=002 be_modify failed (67)
slapd[26324]: do_syncrepl: rid=002 rc 67 retrying

>From the error code ox43, it seems that the replication is somehow
trying to change the rdn, olcDatabase{1}mdb, on the consumer, which
makes no sense to me.

>From the producer, cn=config,cn=slave:
( This is identical to the consumer's cn=config )

dn: cn=config,cn=slave
objectClass: olcGlobal
objectClass: olcConfig
objectClass: top
cn: slaveconfig
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcAttributeOptions: lang-
olcAuthzPolicy: none
olcConcurrency: 0
olcConfigDir: slapd.d/
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexIntLen: 4
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcLocalSSF: 71
olcLogFile: none
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcReadOnly: FALSE
olcSaslSecProps: noplain,noanonymous
olcSizeLimit: 2
olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCACertificatePath: /etc/ssl/certs
olcTLSCertificateFile: /etc/ssl/certs/hkuwildcardcacert.cert
olcTLSCertificateKeyFile: /etc/ssl/private/hkuwildcardcacert.key
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcToolThreads: 2

I'll leave the rest PM, except for:

dn: olcDatabase={0}config,cn=config,cn=slave
objectClass: olcDatabaseConfig
objectClass: olcConfig
objectClass: top
olcDatabase: {0}config
olcRootDN: cn=root,cn=config
olcRootPW: xx
olcSyncrepl: {0}rid=002 provider=ldap://xxx.xx.xx bindmethod=simple
binddn="cn=config,cn=slave" credentials=""
tls_cert="/etc/ssl/certs/xxx.cert" tls_key="/etc/ssl/private/xxx.key"
tls_cacertdir="/etc/ssl/certs" tls_reqcert=demand tls_crlcheck=none
searchbase="cn=config,cn=slave" schemachecking=off
type=refreshAndPersist retry="5 5 10 +" suffixmassage="cn=config"
olcSyncUseSubentry: FALSE

This is identical to the consumers olcDatabase={0}config,cn=config entry.

Hopefully somebody can point me in the right direction!
Many thanks in advance,

gerard



IETF opinion change on "implicit TLS" vs. StartTLS

2018-02-12 Thread Michael Ströder
HI!

To me this rationale for SMTP submission with implicit TLS seems also
applicable to LDAPS vs. StartTLS:

https://tools.ietf.org/html/rfc8314#appendix-A

So LDAPS should not be considered deprecated. Rather it should be
recommended and the _optional_ use of StartTLS should be strongly
discouraged.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature


Re: placeholder problems

2018-02-12 Thread Côme Chilliet
Le jeudi 8 février 2018, 09:59:03 CET Joeri Casteels a écrit :
> Now i would like to assign them directly to the correct unix group depending 
> on the base you start from or Primary group you select.
> If i use this placeholder:Home directory*: /home/%primaryGroup%/%uid% i get 
> the option in the template to select my primary group but it does not fill in 
> the Home Directory correct nor it fills in the correct group.

Hum primaryGroup is not an LDAP field so I don’t think you can use it like 
that. You can use %gidNumber% but I’m not sure it will help.
You can open an issue to make the primary group name available as 
%primaryGroup% in templates but I can’t guarantee it will be added.

> Also setting the passord expiration does not work correctly with the info on 
> the website under placeholder i tried epoch time and it does not work at all 
> to fetch the day of today and add 4years on top for example. Even just 
> fetching the day of today does not work under unix Password Expiration data:

The epoch modifier was added in FusionDirectory 1.2.1 which is not out yet.

> Then there is another small matter i would like to know if there is an easy 
> change for this. My users are allowed to change some info on their own but 
> non of them find the edit button since it’s in the bottom right corner where 
> nobody looks. Is it possible to make these buttons directly under the last 
> frame? Can i edit this myself in de code?

You can create you own CSS theme in which you can change the button display. 
See 
https://fusiondirectory-developer-documentation.readthedocs.io/en/latest/themes/themes.html#replacements-of-css-and-tpl-files

Côme

signature.asc
Description: This is a digitally signed message part.