On Tue, 03 Jul 2012, Dmitri Pal wrote:
On 06/26/2012 04:44 PM, Loris Santamaria wrote:
El mar, 26-06-2012 a las 13:39 -0400, Dmitri Pal escribió:
On 06/26/2012 01:28 PM, Rich Megginson wrote:
On 06/26/2012 11:13 AM, Dmitri Pal wrote:
On 06/26/2012 11:11 AM, Loris Santamaria wrote:
El mar, 26-06-2012 a las 10:35 -0400, Dmitri Pal escribió:
On 06/25/2012 09:02 PM, Loris Santamaria wrote:
Hi,
while using freeIPA as a user database for a samba installation I found
a problem in the enforcement of password policies. FreeIPA password
policies are more detailed than samba's, in freeIPA one may enforce
password history and the number of character classes in a password, but
normally samba connects to freeIPA with the "Directory Manager" so those
policies are not enforced.
Reading the source of ipa_pwd_extop I see there are three possibilities
when changing passwords:
* Password change by the user, with full enforcement of policies
* Password change by an admin, with no enforcement of policies and
the new password is set as expired so the user has to change it
on next logon
* Password change by Directory Manager, with no enforcement of
policies and the password is not set as expired.
None of the aforementioned possibilities are ideal for samba, samba
should connect to freeIPA with a user privileged enough to change
password for all users but with fully enforced policies.
What do you think about this? Would you consider adding such feature?
Would you accept patches?
Can you please explain why samba needs to connect to IPA and change
the passwords?
In what role you use samba? As a file server or as something else?
I am not sure I follow why you need the password change functionality.
There is a way to setup Samba FS with IPA without trying to make IPA a
back end for Samba.
I can try to dig some writeups on the matter if you are interested.
Samba 3 when used as a PDC/BDC can use a LDAP server as its user/group
database. To do that samba connects with a privileged user to the LDAP
directory and manages some attributes of users and groups in the
directory, adding the sambaSAMAccount objectclass and the sambaSID
attribute to users, groups and machines of the domain.
When users of Windows workstations in a samba domain change their
passwords samba updates the sambaNTPassword, userPassword,
sambaLastPwdChange, sambaPwdMustChange attributes of the corresponding
ldap user.
Using freeIPA as ldap user backend for samba works quite well, except
for the password policy problem mentioned in last mail and that it is
hard to mantain in sync the enabled/disabled status of an account.
What is the value of using FreeIPA as a Samba back end in
comparison to other variants?
Why IPA is more interesting than say 389-DS or OpenLDAP or native
Samba?
IPA will keep all of your passwords in sync - userPassword,
sambaNTPassword, sambaLMPassword, and your kerberos passwords. 389
cannot do this - the functionality that does this is provided by an
IPA password plugin. Openldap has a similar plugin, but I think it
is "contrib" and not "officially supported".
I know that Endi did the work to make 389 be a viable back end for
Samba and it passed all the Samba torture tests so I am not sure I
agree with you. Samba does the kerberos operations itself and uses
LDAP as a storage only. This is why I am struggling to understand the
use case. It seems that Loris has a different configuration that I do
not quite understand, thus questions.
What other features of IPA are used in such setup?
Answering these (and may be other) questions would help us to
understand how common is the use case that you brought up.
First of all, the use case is that of using Samba 3 as a Domain
Controller. Here in Venezuela the government itself promotes the use of
free software so most government agencies and industries won't install
Active Directory to administer windows desktops. There are some medium
to large deployments of Samba 3 as a domain controller here, and there
are a number of Linux desktops deployed in the same networks.
When you use Samba 3 as a Domain Controller with a largish number of
users and machines is mandatory to use a Ldap server as a backend, and
for that you have basically two choices which are of course OpenLdap and
389-DS, but those servers have to be combined with some administration
tools to be really useful.
The ideal choice for us is 389-DS with freeIPA as an administration
framework because of:
* Really easy to use to administer users and groups. Those users
and groups are visible from the samba domain and from linux
machines in the IPA realm or from legacy unix and linux machines
configured as ldap clients
* ipa_pwd_extop keeps ldap, samba and kerberos passwords in sync.
Well, this could be better
* freeIPA sets up 389-ds very well, with sane indexes and
permissions. For good performance with samba you just have to
add indexes for some samba attributes
So you set up Samba 3 with freeIPA, and use the ipa tools to administer
users and groups, and those users and group can login in windows and
linux workstations.
To set up Samba 3 with freeIPA 2.x you have to:
* extend the ipa user and group objects to have them add the
sambaSAMAccount and SambaGroupType objectclasses
* add a Distributed Numeric Assignment configuration to have
389-DS generate the sambaSID for objects with the above
objectClasses
* add a script used by samba 3 when a windows machine tries to
join the domain, so that ipa creates a new host if it doesn't
exist
* add indexes for common samba attributes.
The alternative to all this, using free software, would be using samba 4
and have Linux workstations join the Samba 4 domain, or use samba 4 for
the windows domain with a trust relationship to ipa 3 when it is ready.
Thank you,
Loris Santamaria
Thank you for the detailed explanation.
It makes perfect sense now.
Since the LDAP back ends are not supported by Samba we either have to
support them ourselves or make an effort to allow joining the Windows
workstations into the IPA domain. IMO the latter is a more promising
smbd from Samba 4 supports LDAP backends. Samba 4 AD DC does not support
a separate LDAP backend, it uses its integrated LDAP server
implementation.
So there are two different cases: using smbd or using Samba AD DC. We
can try to cover first one with FreeIPA v3 as we use smbd there already
with LDAP backend but it would still require some work.
avenue in a long run as it would address more use cases than trying to
solve it using old Samba3 DC.
Would be interesting to really have a project that would build an IdM
client for Windows using Kerberos for Windows.
There is a project Opendirectory (in Russian:
http://relay.logotek.ru/~viking/opendirectory/) which attempts to build
its own way to implement this. Instead of using domain infra it uses
KDC+389-ds on Linux side and home-brew Windows 'client' that imports
users and groups from LDAP into local authority storage on each Windows
machine and uses Kerberos (MIT-compatible) to auth them. Source code of
Windows side is available, written in C#.
The issues with such approach are related to local storage sync, SID
inconsistencies, and questionable scalability of the client side. In
addition, there are many challenges ahead in Opendirectory project that
we already solved in FreeIPA in past years, including various 389-ds
plugins.
Simo and I were looking into what it will take to join Windows client to
FreeIPA v3 smbd without introducing Windows-side changes.
On Windows side:
- NT style join
DomainCompatibilityMode=1 causes Windows7 to avoid contacting both
Kerberos and LDAP but fail on creating machine account -- IPA side issue,
can be fixed but we prefer to fix it by creating hosts in IPA during
join.
This will not get Kerberos auth working on Windows side but will still
allow to use Windows machines. The key point here is that single sign-on
will work against smbd and across Windows machines and unified SID management
will be applied to all machines. This is shortest way to get Windows
machines on FreeIPA smbd domain.
- AD style join
DomainCompatibilityMode=0 treats Windows7 into following:
- discover IPA via SRV records
- auth via IPA KDC (successful)
- attempt to connect to IPA LDAP with SASL GSSAPI
- the connection then abruptly stops after LDAP server replies
SASL bind is in progress, no packets are sent from both
sides
389-ds advertises DIGEST-MD5 SASL if cyrus-sasl-digest-md5 package is
installed even if there is no configuration done properly to support
DIGEST-MD5. As result, Windows7 attempts to use DIGEST-MD5 to SASL auth
and LDAP server fails. We have filed ticket for 389-ds to solve this
problem, will be attacked in 1.3 cycle:
https://fedorahosted.org/389/ticket/395
Once we'll solve the 'connection drops' issue, we can see what
Windows wants from our LDAP and how to avert it from contacting. No need
to repeat full AD path here as it simply what Samba 4 AD DC already
gives, so we want to understand if it is possible to convince Windows
that we are NT-style domain yet with Kerberos.
--
/ Alexander Bokovoy
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
