Stephen Winnall's questions

I'm trying to add IPv6 to my network, which uses DHCPv4 with its data stored in an LDAP server. I'm using the Ubuntu module isc-dhcp-server-ldap v4.4.1 to configure the DHCPv4 server and I'm very pleased with it.

I would like to configure my DHCPv6 server the same way. I realise that DHCPv6 options differ from DHCPv4 options and that there is no direct translation from DHCPv4 to DHCPv6.

I would be grateful if someone could confirm that isc-dhcp-server-ldap does in fact support IPv6 and DHCPv6. I have no reason to suspect otherwise, but my attempts at searching for information (things like "LDAP DHCPv6") have revealed suspiciously little information, and a question I placed about this in the Ubuntu support forums elicited no response.

Steve

I have a Synology NAS running Samba that serves up shares in my network. I've set up autofs, LDAP and sssd and can mount Samba home directories on the fly when I log into Linux and MacOS machines.

My shares on the NAS are on an Ext4 volume, i.e. they have never been anything other than Linux files on a Linux filesystem. On the NAS they look like this:

-rwxrwxrwx+ 1 smbowner users    0 Jan 30 03:05 abc
drwxrwxr--+ 2 smbowner users 4096 Jan 30 02:37 bin
-rw-r--r--  1 smbowner users    0 Jan 30 16:43 def

However, on a Linux client they look like this:

---------- 1 netbackup netbackup 0 Jan 30 03:05 abc
drwxr-x--- 2 netbackup netbackup 0 Jan 30 02:37 bin
-rw-r--r-- 1 netbackup netbackup 0 Jan 30 16:43 def

All of the files were created on the Linux client. And they all initially had the file mode 000, like abc has in the example above. If I change the file mode on the NAS, as I did for def, the change is passed through to the client, as above (0644). However, if I do chmod 0644 on the client side, I get an error message ("changing permissions of 'abc': Operation not supported") but it does it anyway :-) and the result on the NAS is 0666.

In the listing on the NAS side, there are + signs after the file mode, indicating that the files have "syno ACLs", which are proprietary Synology ACLs. These get translated and exported to the client and look like the following when displayed on the client with getcifsacl:

~> getcifsacl def
REVISION:0x1
CONTROL:0x8004
OWNER:S-1-5-21-1620245859-1572950330-1674857983-3068
GROUP:S-1-5-21-1620245859-1572950330-1674857983-1201
ACL:S-1-5-21-1620245859-1572950330-1674857983-3068:ALLOWED/OI|CI/0x1201df
ACL:S-1-5-21-1620245859-1572950330-1674857983-1201:ALLOWED/OI|CI/R
ACL:Everyone@WORLD AUTHORITY:ALLOWED/OI|CI/R
ACL:S-1-5-88-3-33188:DENIED/0x0/
ACL:S-1-5-88-1-1034:DENIED/0x0/
ACL:S-1-5-88-2-100:DENIED/0x0/

Clearly, something is wrong here: the SIDs should have been 'idmapped' into something recognisable to a Linux user.

The autofs command (extracted from LDAP) with which the Samba share is mounted is:

-fstype=cifs,vers=3.1.1,cifsacl,perm,mapposix,user_xattr,domain=<dom>,rw,credentials=<file>,file_mode=0640,dir_mode=0750,uid=&,gid=& ://<machine>/<UNC>

My understanding is that the option cifsacl should have caused the SIDs above to be 'idmapped'. It should also have fixed the file modes too...

On the basis of what I have gleaned from various sources in the web, I have the impression that I need somehow to configure sssd (on the client?) and smbd (on the NAS?) with idmap data. My problem is that I haven't been able to find any information on how to do this in the absence of an Active Directory Domain Controller.

Are my conclusions correct thus far? And is there a way of making sssd and smbd work together to make the permissions on the NAS and on the client resemble each other? Or should I be looking at something else?

I have spent some time setting up LDAP-based authentication in my MacOS, iOS and Linux network, taking account of the special quirks of MacOS and Synology (my NAS). SSH login (SSH keys etc.) works and Samba share mounts work. It was all quite fiddly, and I now know more about LDAP than I ever anticipated.

However...

Having reached a point where I could (at least in theory) log into any machine in my network, I thought it would be nice for users to also have access to the same home directory everywhere. No problem: autofs, which can also be managed from LDAP! Or so I thought...

I'm trying something like the following to set up Samba home directories for autofs:

cn=*,ou=auto.home,cn=automount,cn=etc,dc=home,dc=arpa
cn: *
objectClass: automount
objectClass: top
automountInformation: -fstype=cifs,vers=3.0,domain=HOME,rw,username=&,uid=&,gid=& ://s-sy-00.local/home

Some background:

1. s-sy-00.local is my Synology NAS where the home directories will live.
2. /home is UNC of the home directory share that Synology serves up for the user defined in username=.

The problems start when I log in to a remote machine with SSH. autofs tries to mount the user's home directory, but needs the user's password. I can put the password into a password= parameter in the automountInformation line, or I can put the username and the password into a credentials file that I pass with the credentials= parameter. Both approaches lead to added complexity (an automount entry for each user) and duplication (same username and password in two different places: LDAP and the credentials file or the automount and the posixUser in LDAP).

Is there a standard way of dealing with this problem? My search engine skills have not turned anything up yet.

It seems to me that there are three possible solutions:

1. the one that is obvious to every one else but not to me;
2. using the SSH key to mount a credentials file per user (possibly dynamically generated from LDAP) from an SSHFS share;
3. using Kerberos for a full-blown SSO.

I would prefer number 1 :-) I have an aversion to Kerberos: it seems to be overkill and is certainly relatively complex.

Can anyone offer some words of wisdom to give me a flying start into the new year?

I have set up a pair of OpenLDAP servers on Ubuntu 20 with directional failover using Syncrepl. Things that an LDAP user can successfully do include:

• login
• su - <uid>
• remote bind from PHPLDAPAdmin or Apache Directory Studio
• id <uid>

However, the same LDAP user cannot use SSH to login. (Local users can.) The following is an extract from the OpenLDAP server log:

Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 fd=20 ACCEPT from IP=127.0.0.1:60066 (IP=0.0.0.0:389)
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=0 BIND dn="cn=admin,dc=878,dc=home,dc=arpa" method=128
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=0 BIND dn="cn=admin,dc=878,dc=home,dc=arpa" mech=SIMPLE ssf=0
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=0 RESULT tag=97 err=0 text=
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=1 SRCH base="dc=house,dc=878,dc=home,dc=arpa" scope=2 deref=0 filter="(uid=webmin)"
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=1 SRCH attr=host authorizedService shadowExpire shadowFlag shadowInactive shadowLastChange shadowMax shadowMin shadowWarning uidNumber
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=2 BIND anonymous mech=implicit ssf=0
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=2 BIND dn="uid=webmin,ou=users,dc=house,dc=878,dc=home,dc=arpa" method=128
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=2 RESULT tag=97 err=49 text=
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=3 BIND dn="cn=admin,dc=878,dc=home,dc=arpa" method=128
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=3 BIND dn="cn=admin,dc=878,dc=home,dc=arpa" mech=SIMPLE ssf=0
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=3 RESULT tag=97 err=0 text=

The bind attempt for the user (uid=webmin) results in error 49, i.e. invalid credentials. The very same credentials are, however, valid for the other cases listed above.

I have had this problem for some while now, and, in my despair, I tried to solve it by installing SSSD. This is only important to explain that, in the log above, I don't know in the first line (ACCEPT from IP=127.0.0.1:60066) whether the OpenLDAP server is talking to SSSD or SSH. It seems clear, though, that it is not speaking StartTLS, which is otherwise does. Is that significant? Would the OpenLDAP server reject an authentication attempt on principle because it isn't StartTLS?

I have run pam-auth-update and told it that I'm using LDAP, SSSD, etc., but it made no difference despite one or two small changes in the common-* files.

I don't know how to debug this. And I've run out of things to google. Can anyone help me please?

I am thinking about installing a POE switch in my gigabit network. I only need the switch to draw power from the network (PD link) but not supply it to other devices (so no PSE links).

What impact does drawing power over the PD port have on data throughput on that link? I'm guessing data throughput is reduced: how significant is this?

I live and work in a building that is nearly 20 years old. My Internet connection is in the cellar along with my servers and has a nominal rating of 100 MBit. I have a gigabit switch in the cellar connecting everything up.

That gigabit switch has a direct ethernet connection to a second gigabit switch three storeys up in my office.

I have tested the speed of the connection from upstairs to the cellar and am getting about 80 Mbit, somewhat less than the nominal speed of my Internet connection. I could live with that, but it would be nice to have a faster connection to my servers, so I'd like a gigabit connection between the switches.

Inspection of the cable from the office to the cellar revealed that it is an ISO/IEC 11801. There is no room in the cable duct for a thicker cable (e.g. CAT6 etc.) because the duct also carries a TV cable.

It seems to me, therefore, that a good way forward would be to put in a duplex fibre optic cable between the two switches and interface it with a gigabit media converter at each end. Is it really as simple as that?

The thing I know I really don't understand is the cable confection. Can one simply cut fibre optic cable to length, and connect it to wall sockets and SC or LC connectors? I can't use ready-made cables because the connectors won't fit down the duct, I think.

If someone could point me at a "howto" or share their wisdom and experience with me, I'd be very grateful.

Steve