1:28 a.m.
Hi all,
since my first test with the debops_service_slapd role and an slapd
server worked at a first glance I now run into an error:
My proceeding was like:
Set up an slapd server with
debops bootstrap -l test-ldap.test.example.de
(-> put host in group debops_service_slapd)
debops -l test-ldap.test.example.de
slapd server is up and running and i can connect with ssl and the
cn=admin user via ldapsearch.
next step was:
debops ldap/init-directory -l test-ldap.test.example.de -vvv
and now I get:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
task path:
/usr/local/share/debops/debops/ansible/roles/ldap/tasks/ldap_tasks.yml:6
The full traceback is:
Traceback (most recent call last):
File
"/tmp/ansible_ldap_entry_payload_ks3b4tbf/ansible_ldap_entry_payload.zip/ansible/module_utils/ldap.py",
line 66, in _connect_to_ldap
connection.start_tls_s()
File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 864, in
start_tls_s
return self._ldap_call(self._l.start_tls_s)
File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 329, in
_ldap_call
reraise(exc_type, exc_value, exc_traceback)
File "/usr/lib/python3/dist-packages/ldap/compat.py", line 44, in reraise
raise exc_value
File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 313, in
_ldap_call
result = func(*args,**kwargs)
ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server",
'errno': 22,
'info': 'Invalid argument'}
fatal: [test-ldap.test.example.de -> localhost]: FAILED! => changed=false
details: '{''desc'': "Can''t contact LDAP server",
''errno'': 22,
''info'': ''Invalid argument''}'
invocation:
module_args:
attributes: {}
bind_dn: cn=admin,dc=test,dc=example,dc=de
bind_pw: VALUE_SPECIFIED_IN_NO_LOG_PARAMETER
dn: cn=admin,dc=test,dc=example,dc=de
objectClass: null
params: null
server_uri: ldaps://test-ldap.test.example.de
start_tls: true
state: absent
validate_certs: true
msg: Cannot start TLS.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error messages sounds like there is a problem with tls. But ldapsearch
with TLS seems to work and pki looks fine.
Any idea?
Kind regards
Jan
4:10 a.m.
Hi Jan,
I think I had similar problems
My guess is that the client is trying to connect to the wrong port on
the wrong uri. Since enable_tls (StartTLS over port 389) is true, but
the uri is ldaps:// (SSL over port 636), the StartTLS request fails. The
client should try to connect to ldap:// or the variable ldap__start_tls
could be set to false.
SSL is flagged as deprecated in the debops documentation, but I remember
wondering why TLS is preferred when I read it.
Having now researched it the last 10 Minutes I am still unsure. LDAPS
has been deprecated since 2000 but there seem to exist good reasons to
still force a wholly encrypted session by using LDAPS. See this blogpost
and comments:
https://averageguyx.blogspot.com/2019/04/ldaps-is-dead-long-live-ldaps.html
Hope that helped and now to, ugh, sleep.
On 31.03.21 01:28, Jan Kowalsky wrote:
> Hi all,
>
> since my first test with the debops_service_slapd role and an slapd
> server worked at a first glance I now run into an error:
>
> My proceeding was like:
>
> Set up an slapd server with
>
> debops bootstrap -l test-ldap.test.example.de
>
> (-> put host in group debops_service_slapd)
>
> debops -l test-ldap.test.example.de
>
> slapd server is up and running and i can connect with ssl and the
> cn=admin user via ldapsearch.
>
> next step was:
>
> debops ldap/init-directory -l test-ldap.test.example.de -vvv
>
> and now I get:
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> task path:
> /usr/local/share/debops/debops/ansible/roles/ldap/tasks/ldap_tasks.yml:6
> The full traceback is:
> Traceback (most recent call last):
> File
>
"/tmp/ansible_ldap_entry_payload_ks3b4tbf/ansible_ldap_entry_payload.zip/ansible/module_utils/ldap.py",
> line 66, in _connect_to_ldap
> connection.start_tls_s()
> File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 864, in
> start_tls_s
> return self._ldap_call(self._l.start_tls_s)
> File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 329, in
> _ldap_call
> reraise(exc_type, exc_value, exc_traceback)
> File "/usr/lib/python3/dist-packages/ldap/compat.py", line 44, in
reraise
> raise exc_value
> File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 313, in
> _ldap_call
> result = func(*args,**kwargs)
> ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server",
'errno': 22,
> 'info': 'Invalid argument'}
> fatal: [test-ldap.test.example.de -> localhost]: FAILED! => changed=false
> details: '{''desc'': "Can''t contact LDAP
server", ''errno'': 22,
> ''info'': ''Invalid argument''}'
> invocation:
> module_args:
> attributes: {}
> bind_dn: cn=admin,dc=test,dc=example,dc=de
> bind_pw: VALUE_SPECIFIED_IN_NO_LOG_PARAMETER
> dn: cn=admin,dc=test,dc=example,dc=de
> objectClass: null
> params: null
> server_uri: ldaps://test-ldap.test.example.de
> start_tls: true
> state: absent
> validate_certs: true
> msg: Cannot start TLS.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Error messages sounds like there is a problem with tls. But ldapsearch
> with TLS seems to work and pki looks fine.
>
> Any idea?
>
> Kind regards
> Jan
9:28 a.m.
On mar 31, Jan Kowalsky wrote:
since my first test with the debops_service_slapd role and an slapd
server worked at a first glance I now run into an error:
slapd server is up and running and i can connect with ssl and the
cn=admin user via ldapsearch.
You tested this on the remote host itself? The 'pki' role ensures that the
DebOps internal CA is trusted, but hosts outside of the DebOps control, like
the Ansible Controller itself if you don't manage it with DebOps, don't trust
the new CA by default.
next step was:
debops ldap/init-directory -l test-ldap.test.example.de -vvv
and now I get:
Error messages sounds like there is a problem with tls. But
ldapsearch
with TLS seems to work and pki looks fine.
Did you run the 'ldapsearch' command from the Ansible Controller itself?
DebOps 'ldap' role runs the LDAP tasks on the Ansible Controller and contacts
the LDAP server remotely.
You might need to add the DebOps CA to your system CA certificate store. If
it's Debian-based, you can put the created RootCA certificate from
'secret/pki/ca-certificates/' directory in
'/usr/local/share/ca-certificates/'
directory on your system and run 'update-ca-certificates'. After that your
local 'ldapsearch' client should trust the CA and be able to talk with the
server.
Let me know if that fixed the issue.
Cheers,
Maciej
12:43 p.m.
Hi Maciej,
thanks for answer.
Am Mittwoch, den 31.03.2021, 09:28 +0200 schrieb Maciej Delmanowski:
On mar 31, Jan Kowalsky wrote:
> since my first test with the debops_service_slapd role and an slapd
> server worked at a first glance I now run into an error:
>
> slapd server is up and running and i can connect with ssl and the
> cn=admin user via ldapsearch.
You tested this on the remote host itself? The 'pki' role ensures
that the
yes, the ldapsearch command I tested on the remote host.
DebOps internal CA is trusted, but hosts outside of the DebOps
control, like
the Ansible Controller itself if you don't manage it with DebOps,
don't trust
the new CA by default.
I understand. You are right. Since we use an ansible controller for
multiple debops projects the ca's from the several projects weren't
included in the ca-certificates of the controller.
> next step was:
>
> debops ldap/init-directory -l test-ldap.test.example.de -vvv
>
> and now I get:
> Error messages sounds like there is a problem with tls. But
Did you run the 'ldapsearch' command from the Ansible
Controller
itself?
No, since this isn't easy because the target ldap server is only
reachable through ssh proxy jump and is not directly accessible.
DebOps 'ldap' role runs the LDAP tasks on the Ansible
Controller and
contacts
the LDAP server remotely.
You might need to add the DebOps CA to your system CA certificate
store.
Ok, I did. But this wasn't enough. So my understanding now is that the
ldap commands are executed directly from the controller - so the ldap
port has to be open and routing has to work. I just brought the target
ldap server into the local network and it worked.
Since (most of? all?) other roles just rely on remote ssh connections I
didn't think about this possibility. Is there any reason why the ldap
statements are not executed remote? And is there any possiblity to
change this behaviour?
As long as I understand the ldap server (and all other hosts in the
network?) have to be reachable from the ansible controller for all ldap
based operations. This is in fact a limitation for our purposes.
Is someone have any ideas ...
Thanks and regards
Jan
1:41 p.m.
On mar 31, Jan Kowalsky wrote:
Since (most of? all?) other roles just rely on remote ssh connections
I
didn't think about this possibility. Is there any reason why the ldap
statements are not executed remote? And is there any possiblity to
change this behaviour?
When I designed the 'ldap' role and how it is used within DebOps, I had an
idea that different people could operate on the LDAP directory using their own
credentials from separate Ansible Controllers. For example, you could have
a helpdesk team that handled the deployment of user machines and using their
credentials and ACL configuration they could add new ou=Hosts entries to the
directory without involvement of the main administrators, essentially "joining
the domain" (I think that's how it's done in the AD and FreeIPA?).
Additionally at the time the 'root' UNIX account on the OpenLDAP server did
not have management access to the main LDAP branch, only cn=config, due to
ACLs set in OpenLDAP. This has subsequently changed and now the 'slapd' role
can operate on the main directory tree.
As for handling this in your envionment... The 'ldap' role has
'ldap__admin_delegate_to' variable which can be modified to delegate the tasks
to another host. That way you should be able to setup an "admin" host inside
of your network and run the tasks there over SSH. You would have to take care
of the credentials - probably creating a separate "admin account" would be
best, so that your own credentials are not put somewhere easily accessible.
Check the "LDAP administrative access" section in the 'ldap' role
defaults,
and the corresponding documentation for more details. Let me know if you
managed to handle this.
Cheers,
Maciej
8:19 p.m.
Am Mittwoch, den 31.03.2021, 13:41 +0200 schrieb Maciej Delmanowski:
As for handling this in your envionment... The 'ldap' role has
'ldap__admin_delegate_to' variable which can be modified to delegate
the tasks
to another host. That way you should be able to setup an "admin" host
inside
of your network and run the tasks there over SSH. You would have to
take care
this works perfectly. I just can take the ldap server itselfs.
of the credentials - probably creating a separate "admin
account"
would be
best, so that your own credentials are not put somewhere easily
accessible.
but the creds of the ansible user are still stored in pass and they are
only tranfered temporarily to the controller for this operation. Aren't
they?
What I don't understand: with which credentials the ansible controller
then connects to the slapd server?
We have this task:
TASK [ldap : Remove the default cn=admin object]
this removes the cn=admin,dc=example,dc=org object from DIT. But I can
still connect with the cn=admin user? And debops tasks are executed
also with this user.
Check the "LDAP administrative access" section in the 'ldap' role
defaults,
and the corresponding documentation for more details. Let me know if you
managed to handle this.
Let's say: I begin to understand more and more.
What I don't understand: what is the idea to administer accounts in
ldap directory with debops?
I found the ldap__tasks but don't do anything, e.g.:
ldap__host_tasks:
- name: 'create test user'
#dn: 'uid=dtuser,ou=People,dc=example,dc=org'
dn: '{{ [ "uid=" + "dtuser", ldap__people_rdn ] +
ldap__base_dn }}'
objectClass: [ 'inetOrgPerson' ]
attributes:
cn: 'Debops Test User'
sn: 'User'
givenName: 'Debops'
uid: 'dtuser'
userPassword: 'secret'
What do I have to do to perform this in debops? Or isn't this the idea
behind ldap__tasks? Can we use this for just adding entries to the
directory without enable ldap (ldap__enabled: False).
Actually my plan is to use fusiondirectory for handling posix and
samba3 (nt-style) accounts. I found https://github.com/debops/debops/is
sues/1341 - and I get fusiondirectory basically working.
But I get error on inserting posix users with "Constraint violation
(some attributes not unique, ". Maybe because https://bugs.openldap.org
/show_bug.cgi?id=6825
The same problem occurs when I just try to add a posix user with
gidNumber and a group with same gidNumber manually via ldifs.
Did you ever got errors like this?
Cheers
Jan
11:55 p.m.
On kwi 01, Jan Kowalsky wrote:
> of the credentials - probably creating a separate "admin
account"
> would be
> best, so that your own credentials are not put somewhere easily
> accessible.
but the creds of the ansible user are still stored in pass and they are
only tranfered temporarily to the controller for this operation. Aren't
they?
I wasn't sure. But if it works as you say it does, great!
What I don't understand: with which credentials the ansible
controller
then connects to the slapd server?
The credentials are defined in these variables[1]. By default this will result
in `uid=<local UNIX account>,ou=People,dc=example,dc=org` Distinguished Name.
This can be overridden, either through Ansible inventory, or through a set of
environment variables on the Ansible Controller. This way you can share the
DebOps project directory between multiple people and each person will use
their own credentials, stored in their own `pass` password store, which lives
outside of the DebOps project directory.
[1]:
https://github.com/debops/debops/blob/master/ansible/roles/ldap/defaults/...
We have this task:
TASK [ldap : Remove the default cn=admin object]
this removes the cn=admin,dc=example,dc=org object from DIT. But I can
still connect with the cn=admin user? And debops tasks are executed
also with this user.
The LDAP directory credentials are stored in the olcRootDN and olcRootPW
attributes in the `cn=config` database. The `cn=admin` object created during
installation by the postinstall script is not needed for authentication, and
it may cause confusion if you don't synchronize the passwords if they change.
> Check the "LDAP administrative access" section in the
'ldap' role defaults,
> and the corresponding documentation for more details. Let me know if you
> managed to handle this.
Let's say: I begin to understand more and more.
What I don't understand: what is the idea to administer accounts in
ldap directory with debops?
If it's more than a couple of accounts I would say skip the YAML and go with
LDIF instead. The LDAP tasks that create the entries are almost LDIF-like when
they are written in YAML, and if you do it via Ansible it will be infinitely
slower than with a `slapadd` import. Ansible needs to do a round-trip to
execute a new Python script for each LDAP task ann this takes longer and
longer the more accounts you want to manage.
Go old school - if you have a user database already, generate LDIFs for the
entries and import them. Or if you want to handle updates frequently, write
a script that imports the data from your user database to LDAP directory. It
will be much faster than going with this via Ansible.
I found the ldap__tasks but don't do anything, e.g.:
ldap__host_tasks:
- name: 'create test user'
#dn: 'uid=dtuser,ou=People,dc=example,dc=org'
dn: '{{ [ "uid=" + "dtuser", ldap__people_rdn ] +
ldap__base_dn }}'
objectClass: [ 'inetOrgPerson' ]
attributes:
cn: 'Debops Test User'
sn: 'User'
givenName: 'Debops'
uid: 'dtuser'
userPassword: 'secret'
What do I have to do to perform this in debops? Or isn't this the idea
behind ldap__tasks?
Yes, you can use the ldap__*_tasks variables to manage LDAP entries. You can
define them in the inventory and run the 'debops service/ldap' playbook
against the OpenLDAP hosts to apply the changes.
Can we use this for just adding entries to the directory without
enable ldap
(ldap__enabled: False).
No, this variable activates or deactivates the entire 'ldap' directory - it's
needed since that role is still included in the 'common' playbook and can be
used on non-LDAP enabled hosts this way.
You can write a normal Ansible playbook that uses the 'ldap_entry' and
'ldap_attrs' Ansible modules to manage LDAP entries. There's no need to
involve the DebOps 'ldap' role for this.
Actually my plan is to use fusiondirectory for handling posix and
samba3 (nt-style) accounts. I found https://github.com/debops/debops/is
sues/1341 - and I get fusiondirectory basically working.
But I get error on inserting posix users with "Constraint violation
(some attributes not unique, ". Maybe because https://bugs.openldap.org
/show_bug.cgi?id=6825
The same problem occurs when I just try to add a posix user with
gidNumber and a group with same gidNumber manually via ldifs.
Did you ever got errors like this?
The default LDAP schema in DebOps is the 'rfc2307bis' schema[2]. It changes
a few things, namely makes the posixGroup object clas an AUXILLIARY class,
which lets you apply it to existing objects. You can then create an
inetOrgPerson object with posixGroup class and define gidNumber in a single
object - that's how DebOps handles User Private Groups in LDAP[3].
As for th constraint violation - gidNumber uniqueness is enfoced globally by
the 'slapd' role[4] to avoid collisions and accidental security issues. If you
want to create a new user with unique UID and GID number, it's best to reserve
one via special LDAP objects prepared just for that[5], similar to how
FusionDirectory does it.
[2]:
https://docs.debops.org/en/master/ansible/roles/slapd/ldap-schema.html#th...
[3]:
https://docs.debops.org/en/master/ansible/roles/ldap/ldap-posix.html#posi...
[4]:
https://github.com/debops/debops/blob/master/ansible/roles/slapd/defaults...
[5]:
https://docs.debops.org/en/master/ansible/roles/ldap/ldap-posix.html#next...
I hope that the explanations helped. :-)
Maciej
4:44 p.m.
Hi Maciej,
> But I get error on inserting posix users with "Constraint
> violation
> (some attributes not unique, ". Maybe because https://bugs.openldap
> .org
> /show_bug.cgi?id=6825
>
> The same problem occurs when I just try to add a posix user with
> gidNumber and a group with same gidNumber manually via ldifs.
>
> Did you ever got errors like this?
The default LDAP schema in DebOps is the 'rfc2307bis' schema[2]. It
changes
this I got. fusiondirectory has this rfc2307bis schema on board and I
worked earlier with this in 389-ds.
a few things, namely makes the posixGroup object clas an AUXILLIARY
class,
which lets you apply it to existing objects. You can then create an
inetOrgPerson object with posixGroup class and define gidNumber in a
single
object - that's how DebOps handles User Private Groups in LDAP[3].
Here began the problem in interaction with fusiondirectory and I think
I understood now why:
The User Private Groups are implemented in debops in a very special way
I think. (I don't know how common it is - I haven't found much about.
It seems quite clever because you only need one object - but I think it
restricts interoperability with other tools.
As for th constraint violation - gidNumber uniqueness is enfoced
globally by
the 'slapd' role[4] to avoid collisions and accidental security
issues. If you
want to create a new user with unique UID and GID number, it's best
to reserve
one via special LDAP objects prepared just for that[5], similar to
how
FusionDirectory does it.
FusionDirectory creates two objects for User Private Groups: one in
ou=People and one in ou=Groups, eg:
uid=tuser,ou=people,dc=example,dc=org
cname=tuser,ou=groups,dc=example,dc=org
but both with gidNumber set to the same value.
This clashs with the
/etc/ldap/slapd.d/cn=config/olcDatabase={1}mdb/olcOverlay={2}unique.ldi
f
So I configured:
slapd__tasks:
- name: 'Configure Unique overlay in the main database'
dn: 'olcOverlay={2}unique,olcDatabase={1}mdb,cn=config'
attributes:
olcUniqueURI:
# - 'ldap:///{{ slapd__basedn }}?uidNumber?sub'
# - 'ldap:///{{ slapd__basedn }}?gidNumber?sub'
- 'ldap:///{{ slapd__basedn }}?mail?sub'
- 'ldap:///{{ slapd__basedn
}}?mailAddress,mailAlternateAddress?sub'
- 'ldap:///ou=People,{{ slapd__basedn }}?employeeNumber?sub'
- 'ldap:///ou=People,{{ slapd__basedn }}?uid?sub'
- 'ldap:///ou=People,{{ slapd__basedn }}?gid?sub'
state: 'exact'
(omitted the ldap:///{{ slapd__basedn }}?gidNumber?sub)
and now I can add Users with Private User Groups in fusiondirectory.
They are stored in two objects anyway. But I think this is standard in
many environments. Isn't it?
Probably it would be enough to use
olcUniqueURI:
- 'ldap:///ou=People,{{ slapd__basedn }}?uidNumber?sub'
- 'ldap:///ou=groups,{{ slapd__basedn }}?gidNumber?sub'
Because we only need same gidNumber in People/Groups once.
What's interesting: fusiondirectory understands the objects written
with debops. The default user is shown as posix user and also on
editing everything is stored in one ldap object.
My task is to use openldap and fusiondirectory for an "old style" samba
directory with posix and samba users. This is in my opinion still the
easiest way for mixed environments with mainly linux desktop clients
and central file storage + home on network when we do not need any
domain logon with Windows clients. I wanted to try to map as much as I
can with debops. But we need a grafical user interface for ldap admin
tasks for the local administration inside the organisations.
Cheers
Jan
11:44 p.m.
On kwi 06, Jan Kowalsky wrote:
> a few things, namely makes the posixGroup object clas an
AUXILLIARY class,
> which lets you apply it to existing objects. You can then create an
> inetOrgPerson object with posixGroup class and define gidNumber in
> a single object - that's how DebOps handles User Private Groups in
> LDAP[3].
Here began the problem in interaction with fusiondirectory and I think
I understood now why:
The User Private Groups are implemented in debops in a very special way
I think. (I don't know how common it is - I haven't found much about.
It seems quite clever because you only need one object - but I think it
restricts interoperability with other tools.
By combining the personal object with the group object, the LDAP directory
itself can ensure that the UID/GID stays consistent, there's no need for
external application to keep track when UID or GID changes, moving the check
to outside of the directory. It's a bit tricky, since you need to filter the
groups on the baseDN with specific object classes. Tradeoffs, I suppose.
> As for th constraint violation - gidNumber uniqueness is enfoced
globally
> by the 'slapd' role[4] to avoid collisions and accidental security issues.
> If you want to create a new user with unique UID and GID number, it's best
> to reserve one via special LDAP objects prepared just for that[5], similar
> to how FusionDirectory does it.
FusionDirectory creates two objects for User Private Groups: one in
ou=People and one in ou=Groups, eg:
uid=tuser,ou=people,dc=example,dc=org
cname=tuser,ou=groups,dc=example,dc=org
but both with gidNumber set to the same value.
This clashs with the
/etc/ldap/slapd.d/cn=config/olcDatabase={1}mdb/olcOverlay={2}unique.ldif
So I configured:
slapd__tasks:
- name: 'Configure Unique overlay in the main database'
dn: 'olcOverlay={2}unique,olcDatabase={1}mdb,cn=config'
attributes:
olcUniqueURI:
# - 'ldap:///{{ slapd__basedn }}?uidNumber?sub'
# - 'ldap:///{{ slapd__basedn }}?gidNumber?sub'
- 'ldap:///{{ slapd__basedn }}?mail?sub'
- 'ldap:///{{ slapd__basedn }}?mailAddress,mailAlternateAddress?sub'
- 'ldap:///ou=People,{{ slapd__basedn }}?employeeNumber?sub'
- 'ldap:///ou=People,{{ slapd__basedn }}?uid?sub'
- 'ldap:///ou=People,{{ slapd__basedn }}?gid?sub'
state: 'exact'
(omitted the ldap:///{{ slapd__basedn }}?gidNumber?sub)
Nicely done. :)
and now I can add Users with Private User Groups in fusiondirectory.
They are stored in two objects anyway. But I think this is standard in
many environments. Isn't it?
It is standard, because rfc2037 has the posixGroup as a STRUCTURAL object,
which was later considered to be a mistake, hence rfc2037bis. But, due to the
former schema used by default in many OpenLDAP installations, the separation
of users and groups became the rule, I suppose.
Probably it would be enough to use
olcUniqueURI:
- 'ldap:///ou=People,{{ slapd__basedn }}?uidNumber?sub'
- 'ldap:///ou=groups,{{ slapd__basedn }}?gidNumber?sub'
Because we only need same gidNumber in People/Groups once.
Yeah, I suppose. But that would require external logic to handle any UID/GID
changes, maybe add an 'owner' attribute that points to the owner of
a particular group, and so on. Currently there's no official management
interface for the LDAP directory in DebOps that would do the job.
But the roles in DebOps are flexible enough that the possibility of changing
the defaults is there. Perhaps you could add a guide that explains how to
modify the default configuration to be compatible with FusionDirectory? I'm
sure that many users would be interested in it.
What's interesting: fusiondirectory understands the objects
written
with debops. The default user is shown as posix user and also on
editing everything is stored in one ldap object.
Of course, the underlying LDAP schemas are largely unchanged.
My task is to use openldap and fusiondirectory for an "old
style" samba
directory with posix and samba users. This is in my opinion still the
easiest way for mixed environments with mainly linux desktop clients
and central file storage + home on network when we do not need any
domain logon with Windows clients. I wanted to try to map as much as I
can with debops. But we need a grafical user interface for ldap admin
tasks for the local administration inside the organisations.
At my workplace we have an existing integration database that gathers data
from various sources. Then, a script converts the relevant information and
updates the entries in LDAP, so that a custom interface is not needed.
I suppose if LDAP is your central truth surce about users, you need to have
a way to manage it directly though.
Since it's a Linux-based environment, why not look into Kerberos and NFS
instead of Samba? These should be more "native" than CIFS shares, and perhaps
could be better integrated in your environment, with native UNIX accounts in
the filesystem and so on. And if you don't care too much about secure file
access, Kerberos could be ditched as well. Somehow putting Samba smack in the
middle of Linux environment feels a bit wrong to me.
Cheers,
Maciej
11:46 p.m.
Here began the problem in interaction with fusiondirectory and I
think
I understood now why:
The User Private Groups are implemented in debops in a very special
way
I think. (I don't know how common it is - I haven't found much about.
ok, you describe it here: https://docs.debops.org/en/master/ansible/rol
es/slapd/ldap-schema.html#the-posixgroupid-schema - I should have read
it more carefully ;-)
12:13 a.m.
Am Dienstag, den 06.04.2021, 23:44 +0200 schrieb Maciej Delmanowski:
But the roles in DebOps are flexible enough that the possibility of
changing
the defaults is there. Perhaps you could add a guide that explains
how to
modify the default configuration to be compatible with
FusionDirectory? I'm
sure that many users would be interested in it.
Where would be the right place to do? Is there any "howto" section in
debops documentation?
Since it's a Linux-based environment, why not look into Kerberos
and
NFS
instead of Samba? These should be more "native" than CIFS shares, and
perhaps
could be better integrated in your environment, with native UNIX
accounts in
the filesystem and so on. And if you don't care too much about secure
file
access, Kerberos could be ditched as well. Somehow putting Samba
smack in the
middle of Linux environment feels a bit wrong to me.
Yes, I know, this sounds a little bit weird ;-)
Because we think a lot about this at the moment I gonna share our
thoughts. Maybe other people have comments.
Well, I have to admit that my experiences with kerberos are very
little. My first ldap environment was 389-ds (and it's still our
standard because wie use central kolab groupware) which lacks the
kerberos password overlay openldap has. So the alternative had been
freepa. But this was hard to integrate.
For many small environment NFS and kerberos is overkill in my opinion.
We've had some ltsp installations with sshfs. We also used this with
fat clients. It's secure but leads to some expected issues with destop
environments because of hardlink bugs... So we have actually the choice
in network filesystems:
sshfs: not all filesystem features are supported
nfs: unsafe without kerberos and quite complex with.
nfs+kerberos: secure but complex. Another drawback (but maybe I'm
wrong): we can't use it for statically mounted filesystem without user
interaction because only users have tickets and not machines.
samba: It works, has at least an authentication layer and we need it
anyway for cross-plattform support / BYOD. So we only have to configure
ONE network filesystems. It works surprisingly well - even for /home
over network. A big drawback: we need unix extentions for user homes -
but this is only possible with samba vers=1.0 (https://lists.samba.org/
archive/samba/2017-October/211517.html).
All in all network filesystem situation for linux is everything else
then satisfactory.
Cheers
Jan
12:40 a.m.
On kwi 07, Jan Kowalsky wrote:
> But the roles in DebOps are flexible enough that the possibility
of
> changing the defaults is there. Perhaps you could add a guide that
> explains how to modify the default configuration to be compatible with
> FusionDirectory? I'm sure that many users would be interested in it.
Where would be the right place to do? Is there any "howto" section in
debops documentation?
The bulk of the changes will most likely be in the 'slapd' role, so I would
put the howto in its documentation, for example alongside multi-master
replication one. I'm not sure if you need to change anything related to the
'ldap' role for FusionDirectory; maybe it has a different place to register
hosts.
nfs+kerberos: secure but complex. Another drawback (but maybe
I'm
wrong): we can't use it for statically mounted filesystem without user
interaction because only users have tickets and not machines.
Machines can also have Kerberos tickets - they need to authenticate to the KDC
as well. But I agree that Kerberos is very complex. I haven't even tried to
approach it yet.
samba: It works, has at least an authentication layer and we need it
anyway for cross-plattform support / BYOD. So we only have to configure
ONE network filesystems. It works surprisingly well - even for /home
over network. A big drawback: we need unix extentions for user homes -
but this is only possible with samba vers=1.0 (https://lists.samba.org/
archive/samba/2017-October/211517.html).
That message seems to be from 2017, maybe something changed in the meantime.
There's apparently work done on new POSIX compatibility layer[1], not sure
about the details.
[1]: https://wiki.samba.org/index.php/SMB3-Linux
All in all network filesystem situation for linux is everything else
then satisfactory.
Plan 9 comes to mind... But that's a story for another time. :-)
Cheers,
Maciej
1115
days inactive
1122
days old
11 comments
3 participants
participants (3)
-
Jan Kowalsky -
listerin -
Maciej Delmanowski