Fedora Samba DC for what purpose it is released in Fedora ?

[Dario Lesca]

In Fedora Server there is a suit of package named samba and samba-dc*

These package, with some other, are useful to make Fedora an Active
Directory Domain Controller.

I have decide tu use it into a little lan and convert old samba NT 4
Style into AD-DC (classicupdate).

After few minutes almost everything work well, except for a thing ...
all windows PC cannot access to others windows PC.

I have ask on Samba ML some suggest, but in essence this was the
answer: "...Using MIT with a Samba AD DC is still experimental, you 
should not run it in production..."
https://lists.samba.org/archive/samba/2019-September/225714.html

Then My questions now are:

a) For what purpose it's released Fedora Samba MIT-KERBEROS DC?
b) Someone can help me to debug my issue?

Many thanks

-- 
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)

[Robert Marcano]

On 9/2/19 11:14 AM, Dario Lesca wrote:
>  In Fedora Server there is a suit of package named samba and
> samba-dc*
>  
>  These package, with some other, are useful to make Fedora an Active
>  Directory Domain Controller.
>  
>  I have decide tu use it into a little lan and convert old samba NT 4
>  Style into AD-DC (classicupdate).
>  
>  After few minutes almost everything work well, except for a thing ...
>  all windows PC cannot access to others windows PC.
>  
>  I have ask on Samba ML some suggest, but in essence this was the
>  answer: "...Using MIT with a Samba AD DC is still experimental, you
>  should not run it in production..."
>  https://lists.samba.org/archive/samba/2019-September/225714.html
>  
>  Then My questions now are:
>  
>  a) For what purpose it's released Fedora Samba MIT-KERBEROS DC? 
I think it is only for testing, I think Red Hat team isn't working too 
much on bringing full DC support to Samba, only what is needed for IPA / 
Windows Domains compatibility, but this is my guess.

Testing and helping upstream with the MIT Kerberos is the only option, 
unless enabling Heimdal is possible.

>  b) Someone can help me to debug my issue? 
That was one of the issues I got when testing the Fedora Samba DC build, 
another one was https://bugzilla.samba.org/show_bug.cgi?id=13516 and 
https://bugzilla.samba.org/show_bug.cgi?id=11362

I switched to run Samba DCs on a container with non Fedora / RHEL / 
CentOS provided RPMs. It is the only current option if you want to use 
it on production.

>  
>  Many thanks
>

[Dario Lesca]

Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:
>  I switched to run Samba DCs on a container with non Fedora / RHEL / 
>  CentOS provided RPMs. 
Thank Robert for reply.

Then why don't release samba compiled with Heimdal kerberos?

Just change a flag in build time, and all can use it into a production
environment.

If someone want test MIT version re-change the flag and rebuild it  by
himself .. or release also a samba suite with a specific name (es.
samba-mit-...).

Samba DC is a useful solution in soma case, It is an inconvenience that
we must switch to another distro o use a third part repos  because this
suite into Fedora/RHEL/Centos is a experimental version

Thanks

-- 
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)

[Robert Marcano]

On 9/2/19 11:58 AM, Dario Lesca wrote:
>  Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha
> scritto:
> > I switched to run Samba DCs on a container with non Fedora / RHEL /
> > CentOS provided RPMs.
>  
>  Thank Robert for reply.
>  
>  Then why don't release samba compiled with Heimdal kerberos? 
I was told that some non DC usages of Samba are affected, The MIT 
configuration files will not apply for example. That will change how 
people currently use Samba as a non DC server, for example as a member 
server.

>  
>  Just change a flag in build time, and all can use it into a production
>  environment.
>  
>  If someone want test MIT version re-change the flag and rebuild it  by
>  himself .. or release also a samba suite with a specific name (es.
>  samba-mit-...).
>  
>  Samba DC is a useful solution in soma case, It is an inconvenience that
>  we must switch to another distro o use a third part repos  because this
>  suite into Fedora/RHEL/Centos is a experimental version
>  
>  Thanks
>

[Alexander Bokovoy]

On Mon, 02 Sep 2019, Dario Lesca wrote:
> Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha
> scritto:
> > I switched to run Samba DCs on a container with non Fedora / RHEL /
> > CentOS provided RPMs.
>
> Thank Robert for reply.
>
> Then why don't release samba compiled with Heimdal kerberos?
>
> Just change a flag in build time, and all can use it into a production
> environment. 
We do not support Heimdal builds in Fedora. It is not possible to
reuse
components of Samba built against Heimdal within other applications
compiled against MIT Kerberos. This is, in particular, a show-stopper
for FreeIPA and SSSD integration.

> If someone want test MIT version re-change the flag and rebuild it  by
> himself .. or release also a samba suite with a specific name (es.
> samba-mit-...).
>
> Samba DC is a useful solution in soma case, It is an inconvenience that
> we must switch to another distro o use a third part repos  because this
> suite into Fedora/RHEL/Centos is a experimental version 
You may create your own COPR
repository and support your own build
there. It is up to you to support that solution.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Nico Kadel-Garcia]

On Mon, Sep 2, 2019 at 3:33 PM Alexander Bokovoy <abokovoy(a)redhat.com&gt; wrote:
>  On Mon, 02 Sep 2019, Dario Lesca wrote:
>  >Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:
>  >> I switched to run Samba DCs on a container with non Fedora / RHEL /
>  >> CentOS provided RPMs.
>  >
>  >Thank Robert for reply.
>  >
>  >Then why don't release samba compiled with Heimdal kerberos?
>  >
>  >Just change a flag in build time, and all can use it into a production
>  >environment.
>  We do not support Heimdal builds in Fedora. It is not possible to reuse
>  components of Samba built against Heimdal within other applications
>  compiled against MIT Kerberos. This is, in particular, a show-stopper
>  for FreeIPA and SSSD integration. 
My personal experience is that this is not true. sssd in a recent
Fedora (Fedora 29 last year) works just fine against an honest-to-god
Samba 4.9 domain controller on RHEL 7. I've not tested tested it with
samba 4.11rc2 yeat, as I'm still working on that port. sssd also works
against a real AD controller. sssd does not rely on a freeipa server.
It has genuinely unfortunate behavior of pre-downloading the *entire*
LDAP tree, and breaking if it can't complete this, but that's another
issue that won't be visible in most small test environments with local
domain controllers.

Freeipa..... I started setting up, realized it was going to take
months to replace existing structures and gain me *absolutely nothing*
compared to using the built-in AD or Samba systems already in my
network, and maybe tuning them slightly better.

>  >If someone want test MIT version re-change the flag and rebuild
> it  by
>  >himself .. or release also a samba suite with a specific name (es.
>  >samba-mit-...).
>  >
>  >Samba DC is a useful solution in soma case, It is an inconvenience that
>  >we must switch to another distro o use a third part repos  because this
>  >suite into Fedora/RHEL/Centos is a experimental version
>  You may create your own COPR repository and support your own build
>  there. It is up to you to support that solution. 
In the case of Samba, the support community is quite large. It's been
an active free software project, used worldwide and across multiple
operating systems, since the 1990's. I can vouch for that personally,
I published my first port of it for SunOS in roughly 1998. Nearly
every bulk storage device in the world uses it to provide CIFS
fileshares, many of those bulk storage devices with full domain
controller services available if not activated. It's one of the
cheapest ways to replace an AD domain controller.

FreeIPA.... does not have anywhere near the user and developer
community for servers. And sssd.... well, I've used it for Fedora and
RHEL, because it's a convenient wrapper for what I used to have to do
with the "net ads" command from Samba and is useful for admins who
can't be bothered to put more than one command in a shell script. But
its configurations are confusing, Do not get me *going* on the
interactions of sssd with the very limited "authconfig" command line
tool. And you really, really don't want to get me going on how sssd
insists on pre-loading *all* the upstream LDAP trees, works for 30
seconds and then crashes when the pre-load times out, and there is no
fix or way to restart *just that sssd LDAP sub-daemon*. The sssd damon
wrapping customized sssd subdamons, instead of simply using the
built-in system LDAP daemons is destabilizing and completely
unnecessary.

I'll take a Samba client in a heartbeat over the sssd mess in any even
slightly complex environment. And since the upstream for both sssd and
Samba clients can be the more popular and more supportable AD or Samba
server,  there has been little point to more than the most casual look
at a FreeIPA server.

Are there any significant sets of systems or clients reliant on
FreeIPA specific features? Because maintaining it does not seem worth
the developer effort if not client specifically requires it. I realize
it may be a big vendor project over at Red Hat, but does *anyone*  use
it out of a specific software need?

>  --
>  / Alexander Bokovoy
>  Sr. Principal Software Engineer
>  Security / Identity Management Engineering
>  Red Hat Limited, Finland 
Sorry to chew on your employer, who are very helpful generally and
whose work I normally appreciate. sssd and freeipa have not been
examples of Red Hat's best work and community integration


Nico Kadel-Garcia

[Robert Marcano]

On 9/2/19 4:52 PM, Nico Kadel-Garcia wrote:
>  On Mon, Sep 2, 2019 at 3:33 PM Alexander Bokovoy
> <abokovoy(a)redhat.com&gt; wrote:
> >
> > On Mon, 02 Sep 2019, Dario Lesca wrote:
> >> Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:
> >>> I switched to run Samba DCs on a container with non Fedora / RHEL /
> >>> CentOS provided RPMs.
> >>
> >> Thank Robert for reply.
> >>
> >> Then why don't release samba compiled with Heimdal kerberos?
> >>
> >> Just change a flag in build time, and all can use it into a production
> >> environment.
> > We do not support Heimdal builds in Fedora. It is not possible to reuse
> > components of Samba built against Heimdal within other applications
> > compiled against MIT Kerberos. This is, in particular, a show-stopper
> > for FreeIPA and SSSD integration.
>  
>  My personal experience is that this is not true. sssd in a recent
>  Fedora (Fedora 29 last year) works just fine against an honest-to-god
>  Samba 4.9 domain controller on RHEL 7. I've not tested tested it with
>  samba 4.11rc2 yeat, as I'm still working on that port. sssd also works
>  against a real AD controller. sssd does not rely on a freeipa server.
>  It has genuinely unfortunate behavior of pre-downloading the *entire*
>  LDAP tree, and breaking if it can't complete this, but that's another
>  issue that won't be visible in most small test environments with local
>  domain controllers. 
The parent poster is refering to having two Kerberos implementations on 
the same process, not from two different machines. For example, an 
application linking against Samba libraries with Heimdal and at the same 
time linking with system MIT Kerberos for another features of that 
application unrelated with Samba.

>  
>  Freeipa..... I started setting up, realized it was going to take
>  months to replace existing structures and gain me *absolutely nothing*
>  compared to using the built-in AD or Samba systems already in my
>  network, and maybe tuning them slightly better.
>  
> >> If someone want test MIT version re-change the flag and rebuild it  by
> >> himself .. or release also a samba suite with a specific name (es.
> >> samba-mit-...).
> >>
> >> Samba DC is a useful solution in soma case, It is an inconvenience that
> >> we must switch to another distro o use a third part repos  because this
> >> suite into Fedora/RHEL/Centos is a experimental version
> > You may create your own COPR repository and support your own build
> > there. It is up to you to support that solution.
>  
>  In the case of Samba, the support community is quite large. It's been
>  an active free software project, used worldwide and across multiple
>  operating systems, since the 1990's. I can vouch for that personally,
>  I published my first port of it for SunOS in roughly 1998. Nearly
>  every bulk storage device in the world uses it to provide CIFS
>  fileshares, many of those bulk storage devices with full domain
>  controller services available if not activated. It's one of the
>  cheapest ways to replace an AD domain controller.
>  
>  FreeIPA.... does not have anywhere near the user and developer
>  community for servers. And sssd.... well, I've used it for Fedora and
>  RHEL, because it's a convenient wrapper for what I used to have to do
>  with the "net ads" command from Samba and is useful for admins who
>  can't be bothered to put more than one command in a shell script. But
>  its configurations are confusing, Do not get me *going* on the
>  interactions of sssd with the very limited "authconfig" command line
>  tool. And you really, really don't want to get me going on how sssd
>  insists on pre-loading *all* the upstream LDAP trees, works for 30
>  seconds and then crashes when the pre-load times out, and there is no
>  fix or way to restart *just that sssd LDAP sub-daemon*. The sssd damon
>  wrapping customized sssd subdamons, instead of simply using the
>  built-in system LDAP daemons is destabilizing and completely
>  unnecessary.
>  
>  I'll take a Samba client in a heartbeat over the sssd mess in any even
>  slightly complex environment. And since the upstream for both sssd and
>  Samba clients can be the more popular and more supportable AD or Samba
>  server,  there has been little point to more than the most casual look
>  at a FreeIPA server.
>  
>  Are there any significant sets of systems or clients reliant on
>  FreeIPA specific features? Because maintaining it does not seem worth
>  the developer effort if not client specifically requires it. I realize
>  it may be a big vendor project over at Red Hat, but does *anyone*  use
>  it out of a specific software need?
>  
> > --
> > / Alexander Bokovoy
> > Sr. Principal Software Engineer
> > Security / Identity Management Engineering
> > Red Hat Limited, Finland
>  
>  Sorry to chew on your employer, who are very helpful generally and
>  whose work I normally appreciate. sssd and freeipa have not been
>  examples of Red Hat's best work and community integration
>  
>  
>  Nico Kadel-Garcia
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Nico Kadel-Garcia]

On Mon, Sep 2, 2019 at 9:25 PM Robert Marcano <robert(a)marcanoonline.com&gt; wrote:
>  On 9/2/19 4:52 PM, Nico Kadel-Garcia wrote:
>  > On Mon, Sep 2, 2019 at 3:33 PM Alexander Bokovoy <abokovoy(a)redhat.com&gt; wrote:
>  >>
>  >> On Mon, 02 Sep 2019, Dario Lesca wrote:
>  >>> Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:
>  >>>> I switched to run Samba DCs on a container with non Fedora / RHEL /
>  >>>> CentOS provided RPMs.
>  >>>
>  >>> Thank Robert for reply.
>  >>>
>  >>> Then why don't release samba compiled with Heimdal kerberos?
>  >>>
>  >>> Just change a flag in build time, and all can use it into a production
>  >>> environment.
>  >> We do not support Heimdal builds in Fedora. It is not possible to reuse
>  >> components of Samba built against Heimdal within other applications
>  >> compiled against MIT Kerberos. This is, in particular, a show-stopper
>  >> for FreeIPA and SSSD integration.
>  >
>  > My personal experience is that this is not true. sssd in a recent
>  > Fedora (Fedora 29 last year) works just fine against an honest-to-god
>  > Samba 4.9 domain controller on RHEL 7. I've not tested tested it with
>  > samba 4.11rc2 yeat, as I'm still working on that port. sssd also works
>  > against a real AD controller. sssd does not rely on a freeipa server.
>  > It has genuinely unfortunate behavior of pre-downloading the *entire*
>  > LDAP tree, and breaking if it can't complete this, but that's another
>  > issue that won't be visible in most small test environments with local
>  > domain controllers.
>
>  The parent poster is refering to having two Kerberos implementations on
>  the same process, not from two different machines. For example, an
>  application linking against Samba libraries with Heimdal and at the same
>  time linking with system MIT Kerberos for another features of that
>  application unrelated with Samba. 
Sorry to sound critical, but this is irrelevant because, to use domain
controller enabled Samba, it compiles its own internal Kerberos. There
are other system libraries which Samba shares, such as libtalloc and
libldb, but for the comain controller. As best I can tell with sssd,
it's not been a problem. I did not run FreeIPA at all after some
failed attempts, and found  with Samba compatible completely with AD
and the clients able to work, I had no use for it. So the libraries
did not overlap.

If FreeIPA were dropped from Fedora, would there remain any reason to
prefer MIT Kerberos over Heimdal Kerberos?  It's not that I object to
the MIT Kerberos, I know several of the authors personally as old
friends. But that's not a reason to prefer the software.

> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Alexander Bokovoy]

On Mon, 02 Sep 2019, Nico Kadel-Garcia wrote:
> On Mon, Sep 2, 2019 at 9:25 PM Robert Marcano
> <robert(a)marcanoonline.com&gt; wrote:
> >
> > On 9/2/19 4:52 PM, Nico Kadel-Garcia wrote:
> > > On Mon, Sep 2, 2019 at 3:33 PM Alexander Bokovoy <abokovoy(a)redhat.com&gt;
> wrote:
> > >>
> > >> On Mon, 02 Sep 2019, Dario Lesca wrote:
> > >>> Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:
> > >>>> I switched to run Samba DCs on a container with non Fedora / RHEL /
> > >>>> CentOS provided RPMs.
> > >>>
> > >>> Thank Robert for reply.
> > >>>
> > >>> Then why don't release samba compiled with Heimdal kerberos?
> > >>>
> > >>> Just change a flag in build time, and all can use it into a production
> > >>> environment.
> > >> We do not support Heimdal builds in Fedora. It is not possible to reuse
> > >> components of Samba built against Heimdal within other applications
> > >> compiled against MIT Kerberos. This is, in particular, a show-stopper
> > >> for FreeIPA and SSSD integration.
> > >
> > > My personal experience is that this is not true. sssd in a recent
> > > Fedora (Fedora 29 last year) works just fine against an honest-to-god
> > > Samba 4.9 domain controller on RHEL 7. I've not tested tested it with
> > > samba 4.11rc2 yeat, as I'm still working on that port. sssd also works
> > > against a real AD controller. sssd does not rely on a freeipa server.
> > > It has genuinely unfortunate behavior of pre-downloading the *entire*
> > > LDAP tree, and breaking if it can't complete this, but that's another
> > > issue that won't be visible in most small test environments with local
> > > domain controllers.
> >
> > The parent poster is refering to having two Kerberos implementations on
> > the same process, not from two different machines. For example, an
> > application linking against Samba libraries with Heimdal and at the same
> > time linking with system MIT Kerberos for another features of that
> > application unrelated with Samba.
>
> Sorry to sound critical, but this is irrelevant because, to use domain
> controller enabled Samba, it compiles its own internal Kerberos. There
> are other system libraries which Samba shares, such as libtalloc and
> libldb, but for the comain controller. As best I can tell with sssd,
> it's not been a problem. I did not run FreeIPA at all after some
> failed attempts, and found  with Samba compatible completely with AD
> and the clients able to work, I had no use for it. So the libraries
> did not overlap. 
SSSD itself is buildable against Heimdal. However, for quite a
number of
features it uses MIT Kerberos-provided APIs that do not exist in Heimdal.
This means that when it is built against Heimdal, you cannot use those
features (2FA support, prompting in Kerberos clients, etc).

If you have SSSD built against MIT Kerberos and Samba AD built against
internal Heimdal version, the tools from Samba AD would be linked to
Heimdal libraries. This also means they would be expecting Kerberos
credential cache format the same way as Heimdal expects. If those
credential caches produced by SSSD or a normal kinit (which is MIT
Kerberos in Fedora), they may lose some details/flags or be simply
inaccessible. For example, Heimdal does not know anything about KEYRING
and DIR credential cache types. Also, there is a difference in flags
stored in FILE ccaches.

> If FreeIPA were dropped from Fedora, would there remain any reason to
> prefer MIT Kerberos over Heimdal Kerberos?  It's not that I object to
> the MIT Kerberos, I know several of the authors personally as old
> friends. But that's not a reason to prefer the software. 
As I said, you are in
you own right to build infrastructure as you want.
For example, in modules or in COPR. As a group of maintainers for MIT
Kerberos, Samba, FreeIPA, and SSSD in Fedora we are trying to deliver a
uniform working solution that spans servers and workstations altogether.
As far as I know, one biggest missing piece for Samba AD DC with MIT
backend is a bug with GPO enforcement that is tracked upstream. There
are few others but they are of lesser importance.

When we decided to mark MIT backend for Samba AD as experimental at
Samba upstream, it was our decision (mine and Andrew Bartlett) to allow
MIT support to brew a bit at a slower pace. Samba team's opinion is to
get rid of Heimdal integration eventually and concentrate on a single
supported Kerberos implementation -- MIT Kerberos. It takes time and is
currently suspended due to crypto consolidation work we are doing for
various reasons[1] but we'll get there. There are not so many developers
who are willing to work on core infrastructure components.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Alexander Bokovoy]

On ti, 03 syys 2019, Alexander Bokovoy wrote:
> On Mon, 02 Sep 2019, Nico Kadel-Garcia wrote:
> >On Mon, Sep 2, 2019 at 9:25 PM Robert Marcano <robert(a)marcanoonline.com&gt; wrote:
> >>
> >>On 9/2/19 4:52 PM, Nico Kadel-Garcia wrote:
> >>> On Mon, Sep 2, 2019 at 3:33 PM Alexander Bokovoy <abokovoy(a)redhat.com&gt;
> wrote:
> >>>>
> >>>> On Mon, 02 Sep 2019, Dario Lesca wrote:
> >>>>> Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha
> scritto:
> >>>>>> I switched to run Samba DCs on a container with non Fedora / RHEL
> /
> >>>>>> CentOS provided RPMs.
> >>>>>
> >>>>> Thank Robert for reply.
> >>>>>
> >>>>> Then why don't release samba compiled with Heimdal kerberos?
> >>>>>
> >>>>> Just change a flag in build time, and all can use it into a
> production
> >>>>> environment.
> >>>> We do not support Heimdal builds in Fedora. It is not possible to reuse
> >>>> components of Samba built against Heimdal within other applications
> >>>> compiled against MIT Kerberos. This is, in particular, a show-stopper
> >>>> for FreeIPA and SSSD integration.
> >>>
> >>> My personal experience is that this is not true. sssd in a recent
> >>> Fedora (Fedora 29 last year) works just fine against an honest-to-god
> >>> Samba 4.9 domain controller on RHEL 7. I've not tested tested it with
> >>> samba 4.11rc2 yeat, as I'm still working on that port. sssd also works
> >>> against a real AD controller. sssd does not rely on a freeipa server.
> >>> It has genuinely unfortunate behavior of pre-downloading the *entire*
> >>> LDAP tree, and breaking if it can't complete this, but that's
> another
> >>> issue that won't be visible in most small test environments with local
> >>> domain controllers.
> >>
> >>The parent poster is refering to having two Kerberos implementations on
> >>the same process, not from two different machines. For example, an
> >>application linking against Samba libraries with Heimdal and at the same
> >>time linking with system MIT Kerberos for another features of that
> >>application unrelated with Samba.
> >
> >Sorry to sound critical, but this is irrelevant because, to use domain
> >controller enabled Samba, it compiles its own internal Kerberos. There
> >are other system libraries which Samba shares, such as libtalloc and
> >libldb, but for the comain controller. As best I can tell with sssd,
> >it's not been a problem. I did not run FreeIPA at all after some
> >failed attempts, and found  with Samba compatible completely with AD
> >and the clients able to work, I had no use for it. So the libraries
> >did not overlap.
> SSSD itself is buildable against Heimdal. However, for quite a number of
> features it uses MIT Kerberos-provided APIs that do not exist in Heimdal.
> This means that when it is built against Heimdal, you cannot use those
> features (2FA support, prompting in Kerberos clients, etc).
>
> If you have SSSD built against MIT Kerberos and Samba AD built against
> internal Heimdal version, the tools from Samba AD would be linked to
> Heimdal libraries. This also means they would be expecting Kerberos
> credential cache format the same way as Heimdal expects. If those
> credential caches produced by SSSD or a normal kinit (which is MIT
> Kerberos in Fedora), they may lose some details/flags or be simply
> inaccessible. For example, Heimdal does not know anything about KEYRING
> and DIR credential cache types. Also, there is a difference in flags
> stored in FILE ccaches.
>
> >If FreeIPA were dropped from Fedora, would there remain any reason to
> >prefer MIT Kerberos over Heimdal Kerberos?  It's not that I object to
> >the MIT Kerberos, I know several of the authors personally as old
> >friends. But that's not a reason to prefer the software.
> As I said, you are in you own right to build infrastructure as you want.
> For example, in modules or in COPR. As a group of maintainers for MIT
> Kerberos, Samba, FreeIPA, and SSSD in Fedora we are trying to deliver a
> uniform working solution that spans servers and workstations altogether.
> As far as I know, one biggest missing piece for Samba AD DC with MIT
> backend is a bug with GPO enforcement that is tracked upstream. There
> are few others but they are of lesser importance.
>
> When we decided to mark MIT backend for Samba AD as experimental at
> Samba upstream, it was our decision (mine and Andrew Bartlett) to allow
> MIT support to brew a bit at a slower pace. Samba team's opinion is to
> get rid of Heimdal integration eventually and concentrate on a single
> supported Kerberos implementation -- MIT Kerberos. It takes time and is
> currently suspended due to crypto consolidation work we are doing for
> various reasons[1] but we'll get there. There are not so many developers
> who are willing to work on core infrastructure components. 
Forgot to add a reference I marked as [1] before sending email.

[1]
https://sambaxp.org/fileadmin/user_upload/sambaxp2019-slides/schneider_sa...

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Dario Lesca]

Il giorno mar, 03/09/2019 alle 09.59 +0300, Alexander Bokovoy ha
scritto:
>  Forgot to add a reference I marked as [1] before sending email.
>  
>  [1] 
>
> https://sambaxp.org/fileadmin/user_upload/sambaxp2019-slides/schneider_sa...
>   
All very interesting

I have read all our comment and suggest, but now I'm a bit confused.

What should I have to do now?

I'm interested in helping you to find out what is the
problem "win to win access not work"

What is the next step?

Wait for samba 4.11 (can resolve my problem)?

Debug my problem and fill a bug (on samba or redhat)?

What kind of debug I must do an produce?

Samba DC MIT Kerberos have a Future?

FreeIPA can become a AD-DC server (seem only to join to a MS-AD, or I'm
wrong)? 

Is my problem depending from a "samba NT to AD classicupdate" or would I get the
same problem even if I created a new domain?

Let me know, and if this can help to improve samba AD-DC-MIT, I can
spend a little of my time preparing test environments and testing some scenarios 

Thanks to all

-- 
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)

[Alexander Bokovoy]

On ti, 03 syys 2019, Dario Lesca wrote:
> Il giorno mar, 03/09/2019 alle 09.59 +0300, Alexander Bokovoy ha
> scritto:
> > Forgot to add a reference I marked as [1] before sending email.
> >
> > [1]
> >
> https://sambaxp.org/fileadmin/user_upload/sambaxp2019-slides/schneider_sa...
> >
>
> All very interesting
>
> I have read all our comment and suggest, but now I'm a bit confused.
>
> What should I have to do now?
>
> I'm interested in helping you to find out what is the
> problem "win to win access not work"
>
> What is the next step? 
As I said already in my first response: please file a bug and provide
all debug information and network traces you could. Right now we have no
idea what your environment is, what did you do and so on. This thread is
a speculation about something that you vaguely described as 'win to win
access not work'.

> Wait for samba 4.11 (can resolve my problem)?
>
> Debug my problem and fill a bug (on samba or redhat)?
>
> What kind of debug I must do an produce?
>
> Samba DC MIT Kerberos have a Future?
>
> FreeIPA can become a AD-DC server (seem only to join to a MS-AD, or I'm
> wrong)? 
I cannot parse what you mean here. FreeIPA is not an active directory
domain controller and never supposed to be one. The rest I already
answered several times in this thread.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Dario Lesca]

Il giorno mar, 03/09/2019 alle 12.47 +0300, Alexander Bokovoy ha
scritto:
>  provide all debug information and network traces you could. 
Ok, I will fill de bug into Fedora Bugzilla, I use a Fedora 30 Server.

Someone can tell me what I can get some debug information and network
traffic?

I suppose must enable samba debug and use tcpdump with some filter...

Please, give me some suggest.

Thanks


-- 
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)

[Alexander Bokovoy]

On ti, 03 syys 2019, Dario Lesca wrote:
> Il giorno mar, 03/09/2019 alle 12.47 +0300, Alexander Bokovoy ha
> scritto:
> > provide all debug information and network traces you could.
>
> Ok, I will fill de bug into Fedora Bugzilla, I use a Fedora 30 Server.
>
> Someone can tell me what I can get some debug information and network
> traffic?
>
> I suppose must enable samba debug and use tcpdump with some filter...
>
> Please, give me some suggest. 
Please follow https://www.samba.org/~asn/reporting_samba_bugs.txt

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Robbie Harwood]

Nico Kadel-Garcia <nkadel(a)gmail.com&gt; writes:

>  Robert Marcano <robert(a)marcanoonline.com&gt; wrote:
> > Nico Kadel-Garcia wrote:
> >> Alexander Bokovoy <abokovoy(a)redhat.com&gt; wrote:
> >>> On Mon, 02 Sep 2019, Dario Lesca wrote:
> >>>> Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:
> >>>>>
> >>>>> I switched to run Samba DCs on a container with non Fedora / RHEL /
> >>>>> CentOS provided RPMs.
> >>>>
> >>>> Thank Robert for reply.
> >>>>
> >>>> Then why don't release samba compiled with Heimdal kerberos?
> >>>>
> >>>> Just change a flag in build time, and all can use it into a production
> >>>> environment.
> >>> We do not support Heimdal builds in Fedora. It is not possible to reuse
> >>> components of Samba built against Heimdal within other applications
> >>> compiled against MIT Kerberos. This is, in particular, a show-stopper
> >>> for FreeIPA and SSSD integration.
> >>
> >> My personal experience is that this is not true. sssd in a recent
> >> Fedora (Fedora 29 last year) works just fine against an honest-to-god
> >> Samba 4.9 domain controller on RHEL 7. I've not tested tested it with
> >> samba 4.11rc2 yeat, as I'm still working on that port. sssd also works
> >> against a real AD controller. sssd does not rely on a freeipa server.
> >> It has genuinely unfortunate behavior of pre-downloading the *entire*
> >> LDAP tree, and breaking if it can't complete this, but that's another
> >> issue that won't be visible in most small test environments with local
> >> domain controllers.
> >
> > The parent poster is refering to having two Kerberos implementations
> > on the same process, not from two different machines. For example, an
> > application linking against Samba libraries with Heimdal and at the
> > same time linking with system MIT Kerberos for another features of
> > that application unrelated with Samba.
>
>  Sorry to sound critical, but this is irrelevant because, to use domain
>  controller enabled Samba, it compiles its own internal Kerberos. There
>  are other system libraries which Samba shares, such as libtalloc and
>  libldb, but for the comain controller. As best I can tell with sssd,
>  it's not been a problem. I did not run FreeIPA at all after some
>  failed attempts, and found with Samba compatible completely with AD
>  and the clients able to work, I had no use for it. So the libraries
>  did not overlap.
>
>  If FreeIPA were dropped from Fedora, would there remain any reason to
>  prefer MIT Kerberos over Heimdal Kerberos?  It's not that I object to
>  the MIT Kerberos, I know several of the authors personally as old
>  friends. But that's not a reason to prefer the software. 
Hi, your Fedora krb5 maintainer here.  I have met and work with several
Heimdal developers, and have nothing against them or their project;
they generally do good work.

Heimdal was until very recently inactive upstream.  This resulted in
its removal from Debian for a time, and projects like samba relied on
*heavy* downstream patching of in-tree Heimdal builds to handle this.

MIT krb5 has been the feature leader: plenty of APIs that we wish to use
(e.g., the KEYRING ccache type, or
gss_acquire_cred_from/store_cred_into) simply don't exist on released
versions of Heimdal.

You may also be interested to know of our porting efforts: thanks to
Andreas's work, most of samba now can run on distro builds of MIT krb5.

So if we're going to pick a default to build everything against, we're
going to go with MIT krb5.  But nothing stops us from having heimdal in
Fedora, and indeed we do.  Distributions with more robust alternatives
systems (e.g., Debian) have had packages build against both; in my
opinion this is more effort than it's worth.  You end up exposing all
the compatibility issues (libgssapi is standardized; libkrb5 is not; the
ccache format is ad hoc best effort compatibility; the KDC interlink
protocols are different; etc.), and there's no gain.

If you find something in Heimdal that you need from MIT krb5, I'm happy
to discuss it (over bugzilla); I'm very active in upstream development
and standardization work.

Thanks,
--Robbie
--
Robbie Harwood
Kerberos Development Lead
Security Engineering Team
Red Hat, Inc.
Boston, MA, US

[Nico Kadel-Garcia]

On Tue, Sep 3, 2019 at 2:43 PM Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  Nico Kadel-Garcia <nkadel(a)gmail.com&gt; writes:
>
>  > Robert Marcano <robert(a)marcanoonline.com&gt; wrote:
>  >> Nico Kadel-Garcia wrote:
>  >>> Alexander Bokovoy <abokovoy(a)redhat.com&gt; wrote:
>  >>>> On Mon, 02 Sep 2019, Dario Lesca wrote:
>  >>>>> Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha
> scritto:
>  >>>>>>
>  >>>>>> I switched to run Samba DCs on a container with non Fedora /
> RHEL /
>  >>>>>> CentOS provided RPMs.
>  >>>>>
>  >>>>> Thank Robert for reply.
>  >>>>>
>  >>>>> Then why don't release samba compiled with Heimdal kerberos?
>  >>>>>
>  >>>>> Just change a flag in build time, and all can use it into a
> production
>  >>>>> environment.
>  >>>> We do not support Heimdal builds in Fedora. It is not possible to reuse
>  >>>> components of Samba built against Heimdal within other applications
>  >>>> compiled against MIT Kerberos. This is, in particular, a show-stopper
>  >>>> for FreeIPA and SSSD integration.
>  >>>
>  >>> My personal experience is that this is not true. sssd in a recent
>  >>> Fedora (Fedora 29 last year) works just fine against an honest-to-god
>  >>> Samba 4.9 domain controller on RHEL 7. I've not tested tested it with
>  >>> samba 4.11rc2 yeat, as I'm still working on that port. sssd also works
>  >>> against a real AD controller. sssd does not rely on a freeipa server.
>  >>> It has genuinely unfortunate behavior of pre-downloading the *entire*
>  >>> LDAP tree, and breaking if it can't complete this, but that's
> another
>  >>> issue that won't be visible in most small test environments with local
>  >>> domain controllers.
>  >>
>  >> The parent poster is refering to having two Kerberos implementations
>  >> on the same process, not from two different machines. For example, an
>  >> application linking against Samba libraries with Heimdal and at the
>  >> same time linking with system MIT Kerberos for another features of
>  >> that application unrelated with Samba.
>  >
>  > Sorry to sound critical, but this is irrelevant because, to use domain
>  > controller enabled Samba, it compiles its own internal Kerberos. There
>  > are other system libraries which Samba shares, such as libtalloc and
>  > libldb, but for the comain controller. As best I can tell with sssd,
>  > it's not been a problem. I did not run FreeIPA at all after some
>  > failed attempts, and found with Samba compatible completely with AD
>  > and the clients able to work, I had no use for it. So the libraries
>  > did not overlap. 

>  > If FreeIPA were dropped from Fedora, would there remain any
> reason to
>  > prefer MIT Kerberos over Heimdal Kerberos?  It's not that I object to
>  > the MIT Kerberos, I know several of the authors personally as old
>  > friends. But that's not a reason to prefer the software.
>
>  Hi, your Fedora krb5 maintainer here.  I have met and work with several
>  Heimdal developers, and have nothing against them or their project;
>  they generally do good work. 
And you present some reasons to prefer MIT krb5 overall. Fair enough.
I do note that "dropping FreeIPA" didn't get mentioned. Is it the
primary component of Fedora that relies specifically on MIT krb5?

>  If you find something in Heimdal that you need from MIT krb5, I'm
> happy
>  to discuss it (over bugzilla); I'm very active in upstream development
>  and standardization work.
>
>  Thanks,
>  --Robbie
>  --
>  Robbie Harwood
>  Kerberos Development Lead
>  Security Engineering Team
>  Red Hat, Inc.
>  Boston, MA, US 
All of which is cool, thank you.

[Robbie Harwood]

Nico Kadel-Garcia <nkadel(a)gmail.com&gt; writes:

>  Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
> > Nico Kadel-Garcia <nkadel(a)gmail.com&gt; writes:
> >> Robert Marcano <robert(a)marcanoonline.com&gt; wrote:
> >>> Nico Kadel-Garcia wrote:
> >>>> Alexander Bokovoy <abokovoy(a)redhat.com&gt; wrote:
> >>>>> Dario Lesca wrote:
> >>>>>> Robert Marcano ha scritto:
> >>>>>>>
> >>>>>>> I switched to run Samba DCs on a container with non Fedora /
> RHEL /
> >>>>>>> CentOS provided RPMs.
> >>>>>>
> >>>>>> Thank Robert for reply.
> >>>>>>
> >>>>>> Then why don't release samba compiled with Heimdal kerberos?
> >>>>>>
> >>>>>> Just change a flag in build time, and all can use it into a
> production
> >>>>>> environment.
> >>>>> We do not support Heimdal builds in Fedora. It is not possible to
> reuse
> >>>>> components of Samba built against Heimdal within other applications
> >>>>> compiled against MIT Kerberos. This is, in particular, a
> show-stopper
> >>>>> for FreeIPA and SSSD integration.
> >>>>
> >>>> My personal experience is that this is not true. sssd in a recent
> >>>> Fedora (Fedora 29 last year) works just fine against an honest-to-god
> >>>> Samba 4.9 domain controller on RHEL 7. I've not tested tested it
> with
> >>>> samba 4.11rc2 yeat, as I'm still working on that port. sssd also
> works
> >>>> against a real AD controller. sssd does not rely on a freeipa server.
> >>>> It has genuinely unfortunate behavior of pre-downloading the *entire*
> >>>> LDAP tree, and breaking if it can't complete this, but that's
> another
> >>>> issue that won't be visible in most small test environments with
> local
> >>>> domain controllers.
> >>>
> >>> The parent poster is refering to having two Kerberos implementations
> >>> on the same process, not from two different machines. For example, an
> >>> application linking against Samba libraries with Heimdal and at the
> >>> same time linking with system MIT Kerberos for another features of
> >>> that application unrelated with Samba.
> >>
> >> Sorry to sound critical, but this is irrelevant because, to use domain
> >> controller enabled Samba, it compiles its own internal Kerberos. There
> >> are other system libraries which Samba shares, such as libtalloc and
> >> libldb, but for the comain controller. As best I can tell with sssd,
> >> it's not been a problem. I did not run FreeIPA at all after some
> >> failed attempts, and found with Samba compatible completely with AD
> >> and the clients able to work, I had no use for it. So the libraries
> >> did not overlap.
>
>
> >> If FreeIPA were dropped from Fedora, would there remain any reason to
> >> prefer MIT Kerberos over Heimdal Kerberos?  It's not that I object to
> >> the MIT Kerberos, I know several of the authors personally as old
> >> friends. But that's not a reason to prefer the software.
> >
> > Hi, your Fedora krb5 maintainer here.  I have met and work with several
> > Heimdal developers, and have nothing against them or their project;
> > they generally do good work.
>
>  And you present some reasons to prefer MIT krb5 overall. Fair enough.
>  I do note that "dropping FreeIPA" didn't get mentioned. Is it the
>  primary component of Fedora that relies specifically on MIT krb5? 
No.  You can't switch out implementations after compilation.

krb5 client authentication is very widely used throughout the distro,
and is part of the minimum possible install.  ssh uses it; both firefox
and chromium/chrome use it; the NFS stack uses it;
postgres/mariadb/mysql use it; etc.  Basically, if you have a program
that performs user authentication, it has Kerberos support.  (And if
not, I'm probably interested in adding it :) )

On my fc30:

root@seton:~# dnf repoquery --whatrequires krb5-libs | grep x86_64 | wc -l
...
250

Thanks,
--Robbie

[Alessio]

On Mon, Sep 2, 2019, 5:16 PM Dario Lesca <d.lesca(a)solinos.it&gt; wrote:

>  After few minutes almost everything work well, except for a thing ...
>  all windows PC cannot access to others windows PC.
>  
Wait. I'm not an expert. Said that, are we sure that the cause is krb MIT?
Also on the samba ml it seems a supposition.
Windows PCs are all running windows7?
The same happens with windows 10?

And all these deprecated entries?

krb5kdc[6764](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18),
aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23),
DEPRECATED:arcfour-hmac-exp(24), (-135), DEPRECATED:des-cbc-md5(3)})

>

[Nico Kadel-Garcia]

On Mon, Sep 2, 2019 at 1:56 PM Alessio <alciregi(a)gmail.com&gt; wrote:
>  On Mon, Sep 2, 2019, 5:16 PM Dario Lesca <d.lesca(a)solinos.it&gt; wrote:
> >
> >
> > After few minutes almost everything work well, except for a thing ...
> > all windows PC cannot access to others windows PC.
>
>
>  Wait. I'm not an expert. Said that, are we sure that the cause is krb MIT? Also on
> the samba ml it seems a supposition.
>  Windows PCs are all running windows7?
>  The same happens with windows 10?
>
>  And all these deprecated entries?
>
>  krb5kdc[6764](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18),
> aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24),
> (-135), DEPRECATED:des-cbc-md5(3)}) 
As one of the people who backport current releases Samba to RHEL 7,
with the domain controller enabled, I can vouch that "yes, it's the
Kerberos". My work is over at https://github.com/nkadel/samba4repo,
and it seems to work fairly well with Fedora 30, though I've not
tested it as thoroughly. I have some test rigs in place for samba
4.11rc2 there.

The samba default values are all, by default, set as simply and
generally as possible. Activation of a real domain requires a good
deal of control and authority over local DNS, and the minimal setup
works really well for testers who don't need to start with all that
power and strenuous requirements.

II'd urge you to hop over to the samba-devel or samba mailing lists,
post your smb.conf and version of Samba, and look for debugging help
there.

[Alexander Bokovoy]

On Mon, 02 Sep 2019, Nico Kadel-Garcia wrote:
> On Mon, Sep 2, 2019 at 1:56 PM Alessio <alciregi(a)gmail.com&gt;
> wrote:
> >
> > On Mon, Sep 2, 2019, 5:16 PM Dario Lesca <d.lesca(a)solinos.it&gt; wrote:
> >>
> >>
> >> After few minutes almost everything work well, except for a thing ...
> >> all windows PC cannot access to others windows PC.
> >
> >
> > Wait. I'm not an expert. Said that, are we sure that the cause is krb MIT? Also
> on the samba ml it seems a supposition.
> > Windows PCs are all running windows7?
> > The same happens with windows 10?
> >
> > And all these deprecated entries?
> >
> > krb5kdc[6764](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18),
> aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24),
> (-135), DEPRECATED:des-cbc-md5(3)})
>
> As one of the people who backport current releases Samba to RHEL 7,
> with the domain controller enabled, I can vouch that "yes, it's the
> Kerberos". My work is over at https://github.com/nkadel/samba4repo,
> and it seems to work fairly well with Fedora 30, though I've not
> tested it as thoroughly. I have some test rigs in place for samba
> 4.11rc2 there.
>
> The samba default values are all, by default, set as simply and
> generally as possible. Activation of a real domain requires a good
> deal of control and authority over local DNS, and the minimal setup
> works really well for testers who don't need to start with all that
> power and strenuous requirements.
>
> II'd urge you to hop over to the samba-devel or samba mailing lists,
> post your smb.conf and version of Samba, and look for debugging help
> there. 
As I said in the other response, we need bugs with debug logs and
network traces. Handwaving 'Windows PC cannot see Windows PC' does not
help us to help you to solve the problems you are seeing.

MIT Kerberos in Fedora 30 and rawhide did actively deprecate using of
weak crypto. RC4 is still accessible but system-wide crypto policy blocks its
use by default, so this might explain inability to authenticate with
NTLMSSP, for example (as opposed to use of AES ciphers). So there are
multiple factors that might affect use of Samba AD DC with MIT backend
on Fedora.




> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Tomasz Torcz]

On Mon, Sep 02, 2019 at 05:14:35PM +0200, Dario Lesca wrote:
>  a) For what purpose it's released Fedora Samba MIT-KERBEROS DC?
  This is for FreeIPA interoperability, described at
  https://www.freeipa.org/page/IPA_and_AD

  This is enabled because:
  1) FreeIPA is important part of Fedora deliverables
  2) Samba as DC is not.


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz    .. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.

[Alexander Bokovoy]

On Mon, 02 Sep 2019, Dario Lesca wrote:
> In Fedora Server there is a suit of package named samba and samba-dc*
>
> These package, with some other, are useful to make Fedora an Active
> Directory Domain Controller.
>
> I have decide tu use it into a little lan and convert old samba NT 4
> Style into AD-DC (classicupdate).
>
> After few minutes almost everything work well, except for a thing ...
> all windows PC cannot access to others windows PC.
>
> I have ask on Samba ML some suggest, but in essence this was the
> answer: "...Using MIT with a Samba AD DC is still experimental, you
> should not run it in production..."
> https://lists.samba.org/archive/samba/2019-September/225714.html
>
> Then My questions now are:
>
> a) For what purpose it's released Fedora Samba MIT-KERBEROS DC? 
For testing purposes. There are few bits missing in MIT backend and we
are looking at fixing them at some point.

> b) Someone can help me to debug my issue? 
Please open a bug and provide more details, including debug logs and
network traces that demonstrate your problem.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

On Mon, 2019-09-02 at 17:14 +0200, Dario Lesca wrote:
>  
>  After few minutes almost everything work well, except for a thing ...
>  all windows PC cannot access to others windows PC. 
Hey Dario.
Since in recent days I was testing and evaluating Samba as an AD domain
controller, but using another distro, I decided to configure a F30
server, and try to test what are you experiencing.

I can see a lot of the messages you reported:

Sep 03 01:14:09 adc1 krb5kdc[4059](info): TGS_REQ (5 etypes {aes256-
cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-
hmac(23), DEPRECATED:arcfour-hmac-exp(24), (-135)}) 10.97.69.24: ISSUE:
authtime 1567589350, etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, 
WINUNO$(a)MY.LAN for krbtgt/MY.LAN(a)MY.LAN

But authentication and access to Windows machines (I'm using Windows
10) seems ok: I can join the domain and I can log in with the domain
administrator and with a user crated on the samba server.

Then, it is true that I can't browse the network from the windows PC,
but it could be a group policy or something else.

Accessing a folder shared by windows machine 1 from windows machine 2
doesn't work... if I use the computer name or the fqdn (name resolution
works using nslookup). But if I use the IP address I'm able to access
the shared folder.
Using another distro, I was able to access the shared folder using the
computer name as well.
What is the beavihour you are observing? 
What I mean is: maybe the issue is something in some little
configuration and not a big incompatibility issue preventing you to use
Fedora as DC.

P.S. if this list is not the right place to discuss such topic, we can
go elsewhere.


Thanks,
A.

[Alexander Bokovoy]

On ke, 04 syys 2019, alciregi(a)gmail.com wrote:
> On Mon, 2019-09-02 at 17:14 +0200, Dario Lesca wrote:
> >
> > After few minutes almost everything work well, except for a thing ...
> > all windows PC cannot access to others windows PC.
>
> Hey Dario.
> Since in recent days I was testing and evaluating Samba as an AD domain
> controller, but using another distro, I decided to configure a F30
> server, and try to test what are you experiencing.
>
> I can see a lot of the messages you reported:
>
> Sep 03 01:14:09 adc1 krb5kdc[4059](info): TGS_REQ (5 etypes {aes256-
> cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-
> hmac(23), DEPRECATED:arcfour-hmac-exp(24), (-135)}) 10.97.69.24: ISSUE:
> authtime 1567589350, etypes {rep=aes256-cts-hmac-sha1-96(18),
> tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
> WINUNO$(a)MY.LAN for krbtgt/MY.LAN(a)MY.LAN 
This is not an issue. The message above is normal. It says that WINUNO
machine asked for an initial Kerberos ticket granting ticket, asking for
one of 5 encryption types and got it granted with AES256. The textual
description of those encryption types is a feature we added upstream
this year. DEPRECATED: prefix tells that a particular encryption type is
weak and is marked for removal in future versions of Kerberos (there are
RFCs for this removal).

> But authentication and access to Windows machines (I'm using
> Windows
> 10) seems ok: I can join the domain and I can log in with the domain
> administrator and with a user crated on the samba server. 

> Then, it is true that I can't browse the network from the windows
> PC,
> but it could be a group policy or something else. 
Network browsing requires either
NetBIOS working or LLMNR (the latter is
not implemented by Samba). If you aren't running nmbd, you are not
advertising your servers. Or may be your Windows clients have NetBIOS
discovery disabled.

> Accessing a folder shared by windows machine 1 from windows machine 2
> doesn't work... if I use the computer name or the fqdn (name resolution
> works using nslookup). But if I use the IP address I'm able to access
> the shared folder. 
In the bug that Dario filed, I can see problems with his Windows machine
using low-cased machine name while authenticating with its machine
account to Samba DC -- while being joined with all upper case name. E.g.
using 'foo' instead of 'FOO' as its account name. This doesn't work
with
Kerberos because Kerberos is case-sensitive. But somehow it also doesn't
work with NTLM requests in his logs.

> Using another distro, I was able to access the shared folder using
> the
> computer name as well.
> What is the beavihour you are observing?
> What I mean is: maybe the issue is something in some little
> configuration and not a big incompatibility issue preventing you to use
> Fedora as DC.
>
> P.S. if this list is not the right place to discuss such topic, we can
> go elsewhere. 
We can use https://bugzilla.redhat.com/show_bug.cgi?id=1748860 -- provide your logs there
too.

I still need to see network traces that show breakage between Windows clients.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Dario Lesca]

Il giorno mer, 04/09/2019 alle 14.27 +0300, Alexander Bokovoy ha
scritto:
>  I still need to see network traces that show breakage between
> Windows
>  clients. 
I have update the filezilla bug with tcpdump pcap

-- 
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)

[Robbie Harwood]

Alexander Bokovoy <abokovoy(a)redhat.com&gt; writes:

>  On ke, 04 syys 2019, alciregi(a)gmail.com wrote:
> >On Mon, 2019-09-02 at 17:14 +0200, Dario Lesca wrote:
> >>
> >> After few minutes almost everything work well, except for a thing ...
> >> all windows PC cannot access to others windows PC.
> >
> > Hey Dario.
> > Since in recent days I was testing and evaluating Samba as an AD domain
> > controller, but using another distro, I decided to configure a F30
> > server, and try to test what are you experiencing.
> >
> > I can see a lot of the messages you reported:
> >
> > Sep 03 01:14:09 adc1 krb5kdc[4059](info): TGS_REQ (5 etypes {aes256-
> > cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> > DEPRECATED:arcfour- hmac(23), DEPRECATED:arcfour-hmac-exp(24),
> > (-135)}) 10.97.69.24: ISSUE: authtime 1567589350, etypes
> > {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
> > ses=aes256-cts-hmac-sha1-96(18)}, WINUNO$(a)MY.LAN for
> > krbtgt/MY.LAN(a)MY.LAN
>
>  This is not an issue. The message above is normal. It says that WINUNO
>  machine asked for an initial Kerberos ticket granting ticket, asking for
>  one of 5 encryption types and got it granted with AES256. The textual
>  description of those encryption types is a feature we added upstream
>  this year. DEPRECATED: prefix tells that a particular encryption type is
>  weak and is marked for removal in future versions of Kerberos (there are
>  RFCs for this removal). 
Indeed, they are https://tools.ietf.org/html/rfc8429 and
https://tools.ietf.org/html/rfc6649

The changes are part of
https://fedoraproject.org/wiki/Changes/krb5_crypto_modernization

"Deprecated" has its usual meaning in this context: you should look into
migrating to another enctype if at all possible, and disabling support
for it when you have (because it will be gone in the future, probably
sometime next year).

Thanks,
--Robbie

[Dario Lesca]

Il giorno mer, 04/09/2019 alle 12.48 +0200, alciregi(a)gmail.com ha
scritto:
>  P.S. if this list is not the right place to discuss such topic, we
>  cango elsewhere. 
I have open this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1748860

-- 
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)

[Dario Lesca]

Il giorno mer, 04/09/2019 alle 12.48 +0200, alciregi(a)gmail.com ha
scritto:
>  Accessing a folder shared by windows machine 1 from windows machine
>  2doesn't work... if I use the computer name or the fqdn (name
>  resolutionworks using nslookup). But if I use the IP address I'm able
>  to accessthe shared folder. 
This is also my problem: "win to win access deny" (after a
classicupdate)

Then the problem is not caused by classicupdate, also create a new DC,
new user and join new machine to domain you get same problem

Pleas, add this info to bugzilla.

Thanks

-- 
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)