Migrating from Samba4 to LDAP

[teds]

Hello,

We are attempting to configure our SLES 11 SP3 server to use LDAP for user authentication and active directory.

We currently use Samba4 to manage users and groups, which then control permissions for a number of simple network fileshares on the server, as well as Windows NT logon for our domain computers (no roaming profiles). Our Samba installation uses smbpasswd for the backend authentication.

My question then is, how can I go about configuring our server to import the Samba users/passwords/groups into LDAP and have LDAP take ownership of being the domain controller?

Thanks!
Ted

[ab1]

First, I do not use Samba much, have never used Samba 4 in DC mode, and am
maybe not the best person to answer this.

Could you help me understand the business case behind this migration, and
what services Samba is providing now vs. what you want provided in the
future, as granularly as possible? The reason I ask is that Samba and
LDAP are very different things; one is a set of software meant to provide
file and printer sharing, microsoft active directory (MAD) domain
controller (DC) emulation, and which uses Kerberos a lot for
authentication. The other is a much simpler (perhaps “lightweight” is the
right word) protocol that enables access to, and modification of, objects
in a directory, whether that’s eDirectory, OpenLDAP, Apache DS, or
whatever. Taking a client machine from a “Samba domain” and pointing it
to an LDAP directory means a lot of changes outside of authentication, so
understanding where you are, and where you want to go, will help determine
the path, however rocky.

Next, I believe smbpasswd stores credentials in a hash, and I do not know
that OpenLDAP (presumably, since you mentioned no other backend directory
software) will support input from those files. I am fairly certain you
can point Samba to an LDAP backend for authentication, but it sounds like
you are trying to replace any reliance on the Samba domain with an LDAP
connection, so I do not think Samba/LDAP integration is what you’re after
in the long term.

Maybe somebody knows a great way to setup OpenLDAP to use old Samba passwd
hashes once, then allowing the service to set the OpenLDAP native
password/hash after a successful authentication, but I have never heard of
that (again, this isn’t my area of focus).

What you may want to consider is setting up a simple, TLS/SSL-ized,
website that allows your users to set their password for the first time in
your new LDAP-based environment. It should not be more than a couple
days’ work to have something prototyped that could mail your current users
(assuming you have their e-mail addresses) a one-time password-set link
which, when followed, would allow them to set their initial password in
the LDAP environment. There are probably projects out there that do this
already which could just be re-implemented for the same; I have not tried
it with this particular goal in mind, but PWM is the basis fora
Self-Service Password Reset (SSPR) product I use a fair bit which can do
this type of thing with other directories. https://github.com/pwm-project/pwm

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

[teds]

ab,

Thank you for the thorough response! I will try to address your individual questions below.

[QUOTE=ab;35468]
Could you help me understand the business case behind this migration, and
what services Samba is providing now vs. what you want provided in the
future, as granularly as possible? The reason I ask is that Samba and
LDAP are very different things; one is a set of software meant to provide
file and printer sharing, microsoft active directory (MAD) domain
controller (DC) emulation, and which uses Kerberos a lot for
authentication. The other is a much simpler (perhaps “lightweight” is the
right word) protocol that enables access to, and modification of, objects
in a directory, whether that’s eDirectory, OpenLDAP, Apache DS, or
whatever. Taking a client machine from a “Samba domain” and pointing it
to an LDAP directory means a lot of changes outside of authentication, so
understanding where you are, and where you want to go, will help determine
the path, however rocky.[/QUOTE]

Forgive me, I’m not terribly familiar with the different authentication methods for domains quite yet – that was one of my reasons for posting here. Let me break down what exactly it is I’m looking to implement:

• Samba can continue to control access to shared files and folders (presumably then pointed to LDAP for authentication)
• I’d like to have LDAP take over user-account management (currently managed by Samba)
• I suspect that if LDAP takes over user-account management, it may also need to become the primary Domain Controller for NT-machine logins. If it doesn’t have to, then that’s optional to me.

The reason for having LDAP take over the user management / logins is because I’d like to tie into other software services that require a centralized user authentication database. For example, I have a user portal software suite installed that can either manage its own local users or use an LDAP server to authenticate through. Same goes for our company VPN through a Cisco ASA. I want to be able to centrally manage those instead of asking my users to set up and remember six sets of credentials for six different services.

[QUOTE=ab;35468]
Next, I believe smbpasswd stores credentials in a hash, and I do not know
that OpenLDAP (presumably, since you mentioned no other backend directory
software) will support input from those files. I am fairly certain you
can point Samba to an LDAP backend for authentication, but it sounds like
you are trying to replace any reliance on the Samba domain with an LDAP
connection, so I do not think Samba/LDAP integration is what you’re after
in the long term.[/QUOTE]

I’m indeed using smbpasswd for the Samba credentials, and they are indeed stored in a hash. And yes, I’m basically attempting to do the opposite of what you mentioned – force LDAP to use the Samba backend for authentication, or at least import those credentials and take over management of them.

[QUOTE=ab;35468]
Maybe somebody knows a great way to setup OpenLDAP to use old Samba passwd
hashes once, then allowing the service to set the OpenLDAP native
password/hash after a successful authentication, but I have never heard of
that (again, this isn’t my area of focus).[/QUOTE]

That would be ideal, honestly – but I have no idea either if it’s possible.

@ab;35468

What you may want to consider is setting up a simple, TLS/SSL-ized,
website that allows your users to set their password for the first time in
your new LDAP-based environment. It should not be more than a couple
days’ work to have something prototyped that could mail your current users
(assuming you have their e-mail addresses) a one-time password-set link
which, when followed, would allow them to set their initial password in
the LDAP environment. There are probably projects out there that do this
already which could just be re-implemented for the same; I have not tried
it with this particular goal in mind, but PWM is the basis fora
Self-Service Password Reset (SSPR) product I use a fair bit which can do
this type of thing with other directories. https://github.com/pwm-project/pwm

I’ll have to do some research, but that’s a good place to start!

Thanks,
Ted

[Jens-U]

Hi Ted,

[QUOTE=teds;35478]Forgive me, I’m not terribly familiar with the different authentication methods for domains quite yet – that was one of my reasons for posting here. Let me break down what exactly it is I’m looking to implement:

• Samba can continue to control access to shared files and folders (presumably then pointed to LDAP for authentication)[/QUOTE]
  Samba will have to stay the DC in your target configuration, because:

[QUOTE=teds;35478]- I’d like to have LDAP take over user-account management (currently managed by Samba)

• I suspect that if LDAP takes over user-account management, it may also need to become the primary Domain Controller for NT-machine logins. If it doesn’t have to, then that’s optional to me.[/QUOTE]
  …LDAP will only act as a back-end to store the account information (and some more pieces), but does not have any capabilities to act as a “DC” or any other function within a SaMBa domain (not meaning “driven by the program SAMBA”, but as “using the SMB/… protocols to exchange information and manage resource access”).

What you can do is set up Samba to use LDAP as the account back-end, storing (Samba) groups and users (and machine accounts) within LDAP. But again you’ll see that you’ll have to use some tool not provided by openldap to actually manage the LDAP entries… Samba comes to mind

@teds;35478

The reason for having LDAP take over the user management / logins is because I’d like to tie into other software services that require a centralized user authentication database. For example, I have a user portal software suite installed that can either manage its own local users or use an LDAP server to authenticate through. Same goes for our company VPN through a Cisco ASA. I want to be able to centrally manage those instead of asking my users to set up and remember six sets of credentials for six different services.

I not only like the idea, but actually run such a setup for years. Please be advised that this doesn’t necessarily mean “single sign-on” (same password for each service, per user), only that you’re storing the user-related information (including potentially per-service credentials) in a centralized place (per user - all settings, for all services, may be stored within the same per-user branch of your LDAP tree.) If your services support this, IOW if you find a compatible structure for your LDAP tree, so that all services will be able to access their attributes.

@teds;35478

I’m indeed using smbpasswd for the Samba credentials, and they are indeed stored in a hash. And yes, I’m basically attempting to do the opposite of what you mentioned – force LDAP to use the Samba backend for authentication, or at least import those credentials and take over management of them.

I don’t see a way to do this out of the box. Actually, I don’t see a way to do this even with custom code.

If you setup up Samba to use an LDAP back-end, your users will be able to (re-)set their Samba passwords via standard mechanisms. As setting the password via Samba allows to also update the regular user password (during the same transaction, without further user input), you’d have these two synchronized. If your other services then access their respective elements in the LDAP tree in a conforming way and use either the system login method or verify the user credentials via an LDAP login, you’d be on your way to a single sign-on.

Regards,
J

[teds]

[QUOTE=jmozdzen;35569]Hi Ted,

Samba will have to stay the DC in your target configuration, because… [etc.][/QUOTE]

J,

Thank you so much for the very thorough reply! I agree with your assessment, and see now that Samba is not meant to be used a backend for LDAP, but the other way around. I’m a bit closer to a working Samba/LDAP system now, thanks to some more research.

In between my OP and your reply, I found this thread in the Samba forums and ended up being able to pull all of my Samba users, NT workstations, and their relevant credentials into LDAP. This was the command I used:

pdbedit --import smbpasswd:/etc/samb/smbpasswd

That did the trick quite nicely. However, the main service I’m trying to link up to LDAP requires that users have a either an email or a userPrincipalName attribute to be imported to the service. The command I entered to import the accounts imported all of them as sambaSamAccount,account objectClasses. I’m still only basically familiar with LDAP systems, but it appears that the sambaSamAccount and acccount class schemas do not include attributes for either mail or userPrincipalName.

So, my next two questions are,

1. Is there a way to import users via pdbedit like I have already but with the users being created as objectClasses that include mail or userPrincipalName attributes? or,
2. Is there an equivalent for those attributes in the schema for sambaSamAccount that I’m somehow missing?

The attibute list for the users I’ve created is as follows:

cn description displayName host localityName objectClass organizationName organizationalUnitName sambaAcctFlags sambaBadPasswordCount sambaBadPasswordTime sambaDomainName sambaHomeDrive sambaHomePath sambaKickoffTime sambaLMPassword sambaLogoffTime sambaLogonHours sambaLogonScript sambaLogonTime sambaMungedDial sambaNTPassword sambaPasswordHistory sambaPrimaryGroupSID sambaProfilePath sambaPwdCanChange sambaPwdLastSet sambaPwdMustChange sambaSID sambaUserWorkstations seeAlso uid userid

Thanks!
Ted