On to, 03 joulu 2020, Ronald Wimmer via FreeIPA-users wrote:
I am trying to get a deeper understanding how services are organized.
When browsing the LDAP directory in FreeIPA I can see that services
are organized in a separate (DN:
cn=services,cn=accounts,dc=linux,dc=mydomain,dc=at) and that each
services connection to the computer object can be found in the
ManagedBy attribute. So far, so good.
In the Windows world I see services specified directly in SPN
attributes of a computer object. That makes sense and looks very
similar to the IPA world.
What I do not completely understand is why SPNs cann also be specified
as an attribute of an AD (service account) user. Why? What's the
purpose of that? (almost every tutorial on the web uses the
mapuser-parameter of the ktpass command but none states why this is
needed.) I can imagine that it makes sense for Linux servers when
there is no computer object in the AD. But what are other reasons/use
cases?
I do know that this question is slightly off-topic. Nevertheless, I am
sure somebody here has a good answer to it which I would highly
appreciate to hear.
There is no real connection. Active Directory schema and LDAP DIT are
not 1:1 compatible with FreeIPA's schema and LDAP DIT. FreeIPA design
was to intentionally reduce complexity towards the use cases we have to
handle: POSIX environment where all users and groups are visible to all
systems involved.
Thus, FreeIPA directory information tree is flat, all objects of one
type are children of the same container: cn=users, cn=groups,
cn=computers, cn=services, and so on. Kerberos objects actually located
across most of those subtrees and from Kerberos KDC perspective all what
matters is that there is an object with a particular name and Kerberos
attributes, somewhere under the $SUFFIX of a particular deployment.
One notable difference between AD and FreeIPA way of representing
Kerberos principals is that in FreeIPA there are no real SPNs in a sense
that AD has them. In AD SPNs are basically aliases to computer accounts
on the machines where those services located. A Kerberos key of SPN is
that one of the machine account. In FreeIPA you have services as
separated Kerberos objects. Each of them has by default their own
Kerberos key.
FreeIPA has concept of Kerberos principal aliases. These are more like
SPNs on AD side -- they are just alternative names to existing Kerberos
objects. But we don't really need to share the same key for all services
running on a host, so we do not use Kerberos principal aliases to
represent them. We use aliases for specific use cases where a client
behavior enforces the logic of AD -- this is the case for DCE RPC
communication, for example, where a domain client obtains service tickets
to cifs/... Kerberos principal of a domain controller to authenticate
but uses a service ticket to host/... Kerberos principal to sign own
packets. This means that domain controller needs to use cifs/...
principal key to authenticate the incoming request and host/...
principal key to verify the payload sent by the client.
For the rest of operations we are happily work with separate Kerberos
principals, with their own Kerberos keys.
In Active Directory the functionality you mention (mapuser-parameter of
the ktpass command) is effectively serves two different purposes. If you
run a service on Windows machine, it needs to have some SID under which
its process will run. It can be a machine account object SID but it is
preferred to separate it from the system and run 'unprivileged'. So a
typical approach in AD is to have a 'normal' user account and have an
alias that maps this account to a service.
In FreeIPA world the identity you run service on and its authentication
identity are not so interconnected. You can have Kerberos service in
FreeIPA and still run your actual application service as a local system
account that has no connection to FreeIPA. All you need is a keytab and
a way to initialize your apps Kerberos credentials cache with it.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland