Re: [Freeipa-users] One way trusts
>>I think that the requirement is to have two distinct sets of users >>while you don't have control over one set (AD users) but you have to >>manage the other set (IPA users) somehow. Yup. >I'm yet to see what is the benefit over having only IPA users. Given single >sign-on wasn't a concern, it makes no difference then to specify IPA's user >name during logon from AD machines, so no integration would really be needed. Difference #1 (user experience): Users in AD do not have a new password to remember and/or manage. Difference #2 (administration overhead): I don't have to create users which are already in AD. Difference #3 (political): I'm not duplicating effort of our IT division, I'm serving an un-served community, so there's less "turf" violation. >An attempt to keep users in AD but use IPA features is really asking for >collaboration between the two infrastructure setups. Well, part of the confusion may lie in the fact that much of the functionality in IPA and AD is unfamiliar to me, particularly at the beginning. First and foremost, I'm viewing both AD and IPA as identity stores which can provide Authentication services and store some information about the users which can be used by clients for various purposes: access decisions being a big one. I've been using the LDAP interface to AD because it's easier to understand, and because I can "graft in" my external users via an LDAP metadirectory. This can be done without any infrastructure collaboration, and it provides support for applications which do not allow you to configure more than one domain. Then I started looking at trying to authenticate using Kerberos. Didn't know much about Kerberos when I started. It's supposed to have all sorts of good features. But it also seems to be the layer that introduces the need to collaborate, where before there was none. Early testing seems to indicate that I can in fact "kinit" against AD using a machine not joined to the domain. This gets me a no-address, forwardable TGT, and should suffice to tell the machine that the AD server believes I'm me. I suspect I will run into problems if I then try to use my TGT to get a login ticket for this "host-unknown-to-AD". I'm in the middle of trying to configure sssd on my test VM to use krb5/ldap authentication. It appears I cannot have sssd bind against AD's LDAP interface using Kerberos, or I just haven't figured out how, so the next step is to type my DN and password into another plain text file. Once this works, I'll configure IPA as a second domain on this host. If machines on my research network (which does not share DNS namespace with AD) are joined to any domain, it would be to the FreeIPA domain. I do not quite understand the implications of this with regard to user principles from AD. It seems like it should be possible for me to make groups in FreeIPA which name members from other directories. It also seems like sssd should be capable of making access decisions based on a user principle from one domain and a group from another. But if I understand Kerberos correctly, it will be impossible for the FreeIPA TGS to issue a cross-realm ticket without the required cross realm trust and the associated "remote" principle entries in both directories. I think my ability to make use of FreeIPA's extra (beyond authentication) functionality may depend on exactly where the access control decision is made, and how the information to support that decision is gathered. I'm hoping that sssd can be convinced to make these decisions based on information returned from an LDAP query on the freeIPA server and the TGT from the AD server. Contrary-wise, I'm hoping that I don't need a cross-realm Kerberos ticket from either domain. Thanks for your patience. Sorry its taking so long to come up to speed. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] One way trusts
On Wed, 15 Jan 2014, Petr Spacek wrote: The very same is needed for IPA side. I think we already had discussion on this list how to setup SSSD with two different domains pointing to different Kerberos realms last week but in that case there were non-overlapping DNS namespaces for both Kerberos realms. Now, when an SSH client (PuTTY) on win.example.com will want to connect to lnx.example.com, AD DC on dc.example.com would issue Kerberos ticket to service host/lnx.example@example.com based on own AD credentials. One will be able to login with this ticket to lnx.example.com but nothing from IPA side will apply here: sudo and HBAC rules don't know anything about these users and authentication source. In such situation what I question is the need for IPA deployment at all. If all users will be coming from AD and they are not visible to IPA and not using IPA features, why to spend time with FreeIPA at all? I think that the requirement is to have two distinct sets of users while you don't have control over one set (AD users) but you have to manage the other set (IPA users) somehow. I'm yet to see what is the benefit over having only IPA users. Given single sign-on wasn't a concern, it makes no difference then to specify IPA's user name during logon from AD machines, so no integration would really be needed. An attempt to keep users in AD but use IPA features is really asking for collaboration between the two infrastructure setups. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] One way trusts
On 15.1.2014 08:52, Alexander Bokovoy wrote:
On Wed, 15 Jan 2014, Petr Spacek wrote:
On 15.1.2014 06:49, Alexander Bokovoy wrote:
On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:
Both AD integration solutions we have (synchronization and
cross-forest domain trusts) assume having higher level access
privileges at the time integration is set up.
My problem here is that I'm too ignorable. :) There's over 15000 users
in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD
is being absorbed into the next level up the chain (Forest Service AD
is going to become a part of the overall USDA AD). Then I'm an even
smaller fish, relatively speaking.
I'm unaware of other
mechanisms that would give you the same flexibility and level of
privilege separation between the AD and IPA domains.
?? The current solution using the LDAP interface to AD (and a
metadirectory to merge "external users") provides privilege separation
and the flexibility to add external users. I don't need more; I just
need it to be less clunky. It weakens security, of course, as my AD
password is stored in various plaintext configuration files for each
application needing binding credentials to search for users in AD. I
also have an index to which files contain my password, as it forms a
"password-change-checklist" which I need to run thru every 60 days.
You got me confused on this. You cannot run FreeIPA in such mode because
FreeIPA is not a client-only solution, it is server and client solution.
If you want to stay with an approach where AD is the data source, IPA
server part will not be usable to you and what left is SSSD on the
client side.
SSSD is capable to work as an AD client.
However, if you want all your Linux machines to be enrolled to IPA, they
cannot be enrolled to AD at the same time, this will not work.
Alexander and Jakub, would it be possible to enroll a machine as IPA client
and then manually add AD domain do SSSD configuration?
I guess that this configuration theoretically allows to use one set of users
("external" users) from IPA and also use another set of users ("internal"
users) from AD at the same time. The obvious disadvantage is that you have
to carefully type username@DOMAIN.
This naturally does 'separation' of external and internal users because AD
would know nothing about IPA users and the other way around.
Could it work? I'm just theorizing ... :-)
You can setup SSSD to use multiple sources and you can setup krb5.conf
to serve multiple realms. What you cannot do is to mix and match within
the same DNS namespace over multiple Kerberos realms without being
prepared to things not working now and then.
Suppose you have example.com DNS namespace and four machines:
dc.example.com, win.example.com, lnx.example.com, and ipa.example.com.
They are AD DC, Windows machine, Linux server, and IPA master.
dc.example.com would host Active Directory and own example.com DNS
namespace, including DNS server which hosts example.com zone. Kerberos
realm for AD will be EXAMPLE.COM
ipa.example.com would host IPA master: LDAP server, KDC for IPA realm,
DNS server for example.com with IPA entries. You'd need to define
different Kerberos realm name since you'll need to have different
configurations in krb5.conf on your lnx.example.com. Let's say, it is
IPA-EXAMPLE.COM.
win.example.com is enrolled to AD. It consults dc.example.com for DNS
and Kerberos on logon. It will attempt to get Kerberos tickets to any
service in .example.com through Active Directory domain controller
dc.example.com.
lnx.example.com is enrolled to IPA. You can either manually set up
configuration to point to ipa.example.com everywhere where needed
(through /etc/hosts, /etc/krb5.conf, /etc/sssd/sssd.conf, ...) or point
/etc/resolv.conf to ipa.example.com and assume that split-brain DNS will
work when communicating with win.example.com.
lnx.example.com could be configured to have a second domain in
/etc/sssd/sssd.conf that points to dc.example.com. You need to create a
computer object for lnx.example.com in AD, you need to fetch service
key for host/lnx.example@example.com from AD, and later
maintain it refresh over time but it is possible.
The very same is needed for IPA side. I think we already had discussion
on this list how to setup SSSD with two different domains pointing to
different Kerberos realms last week but in that case there were
non-overlapping DNS namespaces for both Kerberos realms.
Now, when an SSH client (PuTTY) on win.example.com will want to connect
to lnx.example.com, AD DC on dc.example.com would issue Kerberos ticket
to service host/lnx.example@example.com based on own AD credentials.
One will be able to login with this ticket to lnx.example.com but
nothing from IPA side will apply here: sudo and HBAC rules don't know
anything about these users and authentication source.
In such situation what I question is the need for IPA deployment at all.
If all users will be coming from AD and they are not visible
Re: [Freeipa-users] One way trusts
On Wed, 15 Jan 2014, Petr Spacek wrote:
On 15.1.2014 06:49, Alexander Bokovoy wrote:
On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:
Both AD integration solutions we have (synchronization and
cross-forest domain trusts) assume having higher level access
privileges at the time integration is set up.
My problem here is that I'm too ignorable. :) There's over 15000 users
in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD
is being absorbed into the next level up the chain (Forest Service AD
is going to become a part of the overall USDA AD). Then I'm an even
smaller fish, relatively speaking.
I'm unaware of other
mechanisms that would give you the same flexibility and level of
privilege separation between the AD and IPA domains.
?? The current solution using the LDAP interface to AD (and a
metadirectory to merge "external users") provides privilege separation
and the flexibility to add external users. I don't need more; I just
need it to be less clunky. It weakens security, of course, as my AD
password is stored in various plaintext configuration files for each
application needing binding credentials to search for users in AD. I
also have an index to which files contain my password, as it forms a
"password-change-checklist" which I need to run thru every 60 days.
You got me confused on this. You cannot run FreeIPA in such mode because
FreeIPA is not a client-only solution, it is server and client solution.
If you want to stay with an approach where AD is the data source, IPA
server part will not be usable to you and what left is SSSD on the
client side.
SSSD is capable to work as an AD client.
However, if you want all your Linux machines to be enrolled to IPA, they
cannot be enrolled to AD at the same time, this will not work.
Alexander and Jakub, would it be possible to enroll a machine as IPA
client and then manually add AD domain do SSSD configuration?
I guess that this configuration theoretically allows to use one set
of users ("external" users) from IPA and also use another set of
users ("internal" users) from AD at the same time. The obvious
disadvantage is that you have to carefully type username@DOMAIN.
This naturally does 'separation' of external and internal users
because AD would know nothing about IPA users and the other way
around.
Could it work? I'm just theorizing ... :-)
You can setup SSSD to use multiple sources and you can setup krb5.conf
to serve multiple realms. What you cannot do is to mix and match within
the same DNS namespace over multiple Kerberos realms without being
prepared to things not working now and then.
Suppose you have example.com DNS namespace and four machines:
dc.example.com, win.example.com, lnx.example.com, and ipa.example.com.
They are AD DC, Windows machine, Linux server, and IPA master.
dc.example.com would host Active Directory and own example.com DNS
namespace, including DNS server which hosts example.com zone. Kerberos
realm for AD will be EXAMPLE.COM
ipa.example.com would host IPA master: LDAP server, KDC for IPA realm,
DNS server for example.com with IPA entries. You'd need to define
different Kerberos realm name since you'll need to have different
configurations in krb5.conf on your lnx.example.com. Let's say, it is
IPA-EXAMPLE.COM.
win.example.com is enrolled to AD. It consults dc.example.com for DNS
and Kerberos on logon. It will attempt to get Kerberos tickets to any
service in .example.com through Active Directory domain controller
dc.example.com.
lnx.example.com is enrolled to IPA. You can either manually set up
configuration to point to ipa.example.com everywhere where needed
(through /etc/hosts, /etc/krb5.conf, /etc/sssd/sssd.conf, ...) or point
/etc/resolv.conf to ipa.example.com and assume that split-brain DNS will
work when communicating with win.example.com.
lnx.example.com could be configured to have a second domain in
/etc/sssd/sssd.conf that points to dc.example.com. You need to create a
computer object for lnx.example.com in AD, you need to fetch service
key for host/lnx.example@example.com from AD, and later
maintain it refresh over time but it is possible.
The very same is needed for IPA side. I think we already had discussion
on this list how to setup SSSD with two different domains pointing to
different Kerberos realms last week but in that case there were
non-overlapping DNS namespaces for both Kerberos realms.
Now, when an SSH client (PuTTY) on win.example.com will want to connect
to lnx.example.com, AD DC on dc.example.com would issue Kerberos ticket
to service host/lnx.example@example.com based on own AD credentials.
One will be able to login with this ticket to lnx.example.com but
nothing from IPA side will apply here: sudo and HBAC rules don't know
anything about these users and authentication source.
In such situation what I question is the need for IPA deployment at all.
If all users will be coming from AD and they are not visible to IPA and
not using IPA features, wh
Re: [Freeipa-users] One way trusts
On 15.1.2014 06:49, Alexander Bokovoy wrote:
On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:
Both AD integration solutions we have (synchronization and
cross-forest domain trusts) assume having higher level access
privileges at the time integration is set up.
My problem here is that I'm too ignorable. :) There's over 15000 users
in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD
is being absorbed into the next level up the chain (Forest Service AD
is going to become a part of the overall USDA AD). Then I'm an even
smaller fish, relatively speaking.
I'm unaware of other
mechanisms that would give you the same flexibility and level of
privilege separation between the AD and IPA domains.
?? The current solution using the LDAP interface to AD (and a
metadirectory to merge "external users") provides privilege separation
and the flexibility to add external users. I don't need more; I just
need it to be less clunky. It weakens security, of course, as my AD
password is stored in various plaintext configuration files for each
application needing binding credentials to search for users in AD. I
also have an index to which files contain my password, as it forms a
"password-change-checklist" which I need to run thru every 60 days.
You got me confused on this. You cannot run FreeIPA in such mode because
FreeIPA is not a client-only solution, it is server and client solution.
If you want to stay with an approach where AD is the data source, IPA
server part will not be usable to you and what left is SSSD on the
client side.
SSSD is capable to work as an AD client.
However, if you want all your Linux machines to be enrolled to IPA, they
cannot be enrolled to AD at the same time, this will not work.
Alexander and Jakub, would it be possible to enroll a machine as IPA client
and then manually add AD domain do SSSD configuration?
I guess that this configuration theoretically allows to use one set of users
("external" users) from IPA and also use another set of users ("internal"
users) from AD at the same time. The obvious disadvantage is that you have to
carefully type username@DOMAIN.
This naturally does 'separation' of external and internal users because AD
would know nothing about IPA users and the other way around.
Could it work? I'm just theorizing ... :-)
Petr^2 Spacek
If I might try to repeat the problem back to you to see if I got it
right...the factor which requires access to the corporate AD is setting
up a Kerberos cross realm trust. This is required so that machines in
IPA can connect directly to AD for authentication. This in turn is
necessary so that identities in the AD Kerberos Realm are correctly and
consistently identified as being sourced from AD. And of course, this
requirement is necessary for services in AD to recognize users and
groups in AD.
Let me ask what is probably a series of dumb questions: What do I lose
if my FreeIPA server is set up as one of the 10 machines I can join to
the network as a regular user, and all the machines in IPA connect
directly to IPA? Could FreeIPA (current or future) be configured to
relay the credentials to AD either via Kerberos or using AD's LDAP
interface (binding as itself because it's joined to the AD domain)? If
AD accepts the provided credentials can FreeIPA issue the user a ticket
in the FreeIPA realm? Would this look to AD like a bunch of users are
logging into the FreeIPA server machine?
FreeIPA as a server provides own Kerberos realm. AD as a server provides
its own Kerberos realm. In addition, FreeIPA cannot be made a part of
AD forest due to implementation limitations which are not solved yet. We
choose to go with cross-realm trust in which FreeIPA and AD belong to
different forests and trust each other through cross-forest domain trust
in AD speak.
One of implementation details of Kerberos in Active Directory is the
fact that it assumes Kerberos realm is governing DNS namespace. At one
DNS namespace level there could be only one Kerberos realm. If you have
example.com DNS namespace under AD control, no machine in .example.com
can belong to another Kerberos realm -- AD will not issue tickets for
services in that realm even though it would trust it. .ipa.example.com
can be used along with .example.com but there is no way to have
foo.example.com in AD and bar.example.com in IPA and communicate over
Kerberos.
What you are talking about is living in AD namespace (both Kerberos and
DNS) and yet somehow have FreeIPA working with AD users. This is not
possible.
If you want to use Linux clients in AD environments you can use SSSD on
Linux directly connected to AD, without FreeIPA. This way, of course,
you will not get any of FreeIPA benefits like access controls through
HBAC rules and sudo rules.
Dmitri had a talk last week outlining AD integration options we have:
http://www.freeipa.org/images/1/1e/Devconf2013-linux-ad-integration-options.pdf
http://www.youtube.com/watch?v=cS6EJ1L7fRI
I know this arrang
Re: [Freeipa-users] One way trusts
On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote: Both AD integration solutions we have (synchronization and cross-forest domain trusts) assume having higher level access privileges at the time integration is set up. My problem here is that I'm too ignorable. :) There's over 15000 users in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD is being absorbed into the next level up the chain (Forest Service AD is going to become a part of the overall USDA AD). Then I'm an even smaller fish, relatively speaking. I'm unaware of other mechanisms that would give you the same flexibility and level of privilege separation between the AD and IPA domains. ?? The current solution using the LDAP interface to AD (and a metadirectory to merge "external users") provides privilege separation and the flexibility to add external users. I don't need more; I just need it to be less clunky. It weakens security, of course, as my AD password is stored in various plaintext configuration files for each application needing binding credentials to search for users in AD. I also have an index to which files contain my password, as it forms a "password-change-checklist" which I need to run thru every 60 days. You got me confused on this. You cannot run FreeIPA in such mode because FreeIPA is not a client-only solution, it is server and client solution. If you want to stay with an approach where AD is the data source, IPA server part will not be usable to you and what left is SSSD on the client side. SSSD is capable to work as an AD client. However, if you want all your Linux machines to be enrolled to IPA, they cannot be enrolled to AD at the same time, this will not work. If I might try to repeat the problem back to you to see if I got it right...the factor which requires access to the corporate AD is setting up a Kerberos cross realm trust. This is required so that machines in IPA can connect directly to AD for authentication. This in turn is necessary so that identities in the AD Kerberos Realm are correctly and consistently identified as being sourced from AD. And of course, this requirement is necessary for services in AD to recognize users and groups in AD. Let me ask what is probably a series of dumb questions: What do I lose if my FreeIPA server is set up as one of the 10 machines I can join to the network as a regular user, and all the machines in IPA connect directly to IPA? Could FreeIPA (current or future) be configured to relay the credentials to AD either via Kerberos or using AD's LDAP interface (binding as itself because it's joined to the AD domain)? If AD accepts the provided credentials can FreeIPA issue the user a ticket in the FreeIPA realm? Would this look to AD like a bunch of users are logging into the FreeIPA server machine? FreeIPA as a server provides own Kerberos realm. AD as a server provides its own Kerberos realm. In addition, FreeIPA cannot be made a part of AD forest due to implementation limitations which are not solved yet. We choose to go with cross-realm trust in which FreeIPA and AD belong to different forests and trust each other through cross-forest domain trust in AD speak. One of implementation details of Kerberos in Active Directory is the fact that it assumes Kerberos realm is governing DNS namespace. At one DNS namespace level there could be only one Kerberos realm. If you have example.com DNS namespace under AD control, no machine in .example.com can belong to another Kerberos realm -- AD will not issue tickets for services in that realm even though it would trust it. .ipa.example.com can be used along with .example.com but there is no way to have foo.example.com in AD and bar.example.com in IPA and communicate over Kerberos. What you are talking about is living in AD namespace (both Kerberos and DNS) and yet somehow have FreeIPA working with AD users. This is not possible. If you want to use Linux clients in AD environments you can use SSSD on Linux directly connected to AD, without FreeIPA. This way, of course, you will not get any of FreeIPA benefits like access controls through HBAC rules and sudo rules. Dmitri had a talk last week outlining AD integration options we have: http://www.freeipa.org/images/1/1e/Devconf2013-linux-ad-integration-options.pdf http://www.youtube.com/watch?v=cS6EJ1L7fRI I know this arrangement would sacrifice access to any of the AD services by AD-users-on-the-IPA network. That's fine. If it's technically feasible, tho, it gives me one server that can authenticate both "corporate users" and "external users", and a central administration point for the external network. It also plainly differentiates between corporate users logged in on the corporate network, and corporate users logged in on the "external network". I'd consider that a good thing. Finally, if this is possible, it seems to me that this stands a chance of reducing the number of places my password is stored in plaintext. I wish it could be so simple... -- /
Re: [Freeipa-users] One way trusts
On 01/14/2014 05:23 PM, Nordgren, Bryce L -FS wrote: >> Both AD integration solutions we have (synchronization and >> cross-forest domain trusts) assume having higher level access >> privileges at the time integration is set up. > My problem here is that I'm too ignorable. :) There's over 15000 users in our > AD; I'm in Montana, the admins are in DC. Worse, our agency's AD is being > absorbed into the next level up the chain (Forest Service AD is going to > become a part of the overall USDA AD). Then I'm an even smaller fish, > relatively speaking. > >> I'm unaware of other >> mechanisms that would give you the same flexibility and level of >> privilege separation between the AD and IPA domains. > ?? The current solution using the LDAP interface to AD (and a metadirectory > to merge "external users") provides privilege separation and the flexibility > to add external users. I don't need more; I just need it to be less clunky. > It weakens security, of course, as my AD password is stored in various > plaintext configuration files for each application needing binding > credentials to search for users in AD. I also have an index to which files > contain my password, as it forms a "password-change-checklist" which I need > to run thru every 60 days. > > If I might try to repeat the problem back to you to see if I got it > right...the factor which requires access to the corporate AD is setting up a > Kerberos cross realm trust. This is required so that machines in IPA can > connect directly to AD for authentication. This in turn is necessary so that > identities in the AD Kerberos Realm are correctly and consistently identified > as being sourced from AD. And of course, this requirement is necessary for > services in AD to recognize users and groups in AD. > > Let me ask what is probably a series of dumb questions: What do I lose if my > FreeIPA server is set up as one of the 10 machines I can join to the network > as a regular user, and all the machines in IPA connect directly to IPA? Could > FreeIPA (current or future) be configured to relay the credentials to AD > either via Kerberos or using AD's LDAP interface (binding as itself because > it's joined to the AD domain)? If AD accepts the provided credentials can > FreeIPA issue the user a ticket in the FreeIPA realm? Would this look to AD > like a bunch of users are logging into the FreeIPA server machine? > > I know this arrangement would sacrifice access to any of the AD services by > AD-users-on-the-IPA network. That's fine. If it's technically feasible, tho, > it gives me one server that can authenticate both "corporate users" and > "external users", and a central administration point for the external > network. It also plainly differentiates between corporate users logged in on > the corporate network, and corporate users logged in on the "external > network". I'd consider that a good thing. Finally, if this is possible, it > seems to me that this stands a chance of reducing the number of places my > password is stored in plaintext. > > Bryce > You might be able to do one of the following hacks. I am saying hack because no one tried to do it and it might not work and hit some bugs and issues. 1) Use pam proxy capability. If you bind to IPA DS via LDAP you can configure users to authenticate using pam proxy feature of DS and via pam point to AD. This has limitation that it works only for LDAP binds but not for kerberos so your clients would be deprived off SSO. Alternatively you can separate external and internal users. Internal users would be able to do LDAP only while external users since they would be stored in IPA would be able to do both. AFAIU this is not what you want. 2) IPA in 3.3 uses compat tree to present AD data to legacy clients and allow bind to that tree. This is just LDAP so has similar limitations. I suspect it would also rely on the presence of trust to be able to bind to AD but I am not sure. Alexander, CCed would have more details to share for this case. 3) Finally the grand hack that actually might work. IPA 3.3 and 3.4 that is being worked on have OTP support. You will setup winsync to sync AD users (one way from AD), you will make sure that these users can't be modified in IPA via permissions and ACIs so that you do not get into the situation when users become different in IPA and AD. Since you own IPA you will have full control so this part is really up to you. When users are synced in you will add a way of setting additional attributes for the synced in users. I am not sure if this can be done without adding a DS or Winsync plugin but I think it would not be a lot of code for you to do (may be there is a trick that I do not know that might be done to avoid writing a plugin, see below). As a result the synced in users will have following attributes set: **ipatokenRadiusConfigLink - this attribute should point to a RADIUS server configuration object. There will be one such object (see below). All
Re: [Freeipa-users] One way trusts
> Both AD integration solutions we have (synchronization and > cross-forest domain trusts) assume having higher level access > privileges at the time integration is set up. My problem here is that I'm too ignorable. :) There's over 15000 users in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD is being absorbed into the next level up the chain (Forest Service AD is going to become a part of the overall USDA AD). Then I'm an even smaller fish, relatively speaking. > I'm unaware of other > mechanisms that would give you the same flexibility and level of > privilege separation between the AD and IPA domains. ?? The current solution using the LDAP interface to AD (and a metadirectory to merge "external users") provides privilege separation and the flexibility to add external users. I don't need more; I just need it to be less clunky. It weakens security, of course, as my AD password is stored in various plaintext configuration files for each application needing binding credentials to search for users in AD. I also have an index to which files contain my password, as it forms a "password-change-checklist" which I need to run thru every 60 days. If I might try to repeat the problem back to you to see if I got it right...the factor which requires access to the corporate AD is setting up a Kerberos cross realm trust. This is required so that machines in IPA can connect directly to AD for authentication. This in turn is necessary so that identities in the AD Kerberos Realm are correctly and consistently identified as being sourced from AD. And of course, this requirement is necessary for services in AD to recognize users and groups in AD. Let me ask what is probably a series of dumb questions: What do I lose if my FreeIPA server is set up as one of the 10 machines I can join to the network as a regular user, and all the machines in IPA connect directly to IPA? Could FreeIPA (current or future) be configured to relay the credentials to AD either via Kerberos or using AD's LDAP interface (binding as itself because it's joined to the AD domain)? If AD accepts the provided credentials can FreeIPA issue the user a ticket in the FreeIPA realm? Would this look to AD like a bunch of users are logging into the FreeIPA server machine? I know this arrangement would sacrifice access to any of the AD services by AD-users-on-the-IPA network. That's fine. If it's technically feasible, tho, it gives me one server that can authenticate both "corporate users" and "external users", and a central administration point for the external network. It also plainly differentiates between corporate users logged in on the corporate network, and corporate users logged in on the "external network". I'd consider that a good thing. Finally, if this is possible, it seems to me that this stands a chance of reducing the number of places my password is stored in plaintext. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] One way trusts
On 01/13/2014 11:50 PM, Alexander Bokovoy wrote: > Hi, > > On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote: >> Hi Dimitri, >> >>> Just to be sure I understand. You have internal users - they are in >>> AD. You have external users - they are in LDAP. You merge two >>> directories and you want to replace this setup with IPA. >> >> Yes. >> >>> It seems that to support your use case you would need to make the >>> external users be IPA users and make AD and IPA trust each other. >> >> I think I concur about migrating my external users into IPA and making >> IPA trust AD. I may be ignorant of some AD nuance, but I do not see why >> AD needs to trust IPA. AD does not need to trust my LDAP clients >> currently. > IPA needs to be able to look up users and groups in AD. To do so, it > uses Kerberos authentication against AD's Global Catalog services with > own credentials (per each IPA host). We are using cross-realm > Kerberos trust here, AD DC trusts cross-realm TGT issued by IPA KDC and > vice versa, so IPA hosts can bind as their own identity (host/...) to > AD. > > Since we don't implement fully all services needed to grant privileges > beyond read-only in AD, these binds to AD Global Catalog become > read-only. They are still required. An alternative would have been to > always keep an account in AD for each IPA host that needs to query user > and group identities from AD. We decided to go with the cross-realm > Kerberos trust instead since it gives better way of privilege separation. > Cross-realm Kerberos trust is known as cross-forest domain trust in AD > speak since there are more protocol layers than Kerberos involved (SMB > protocol, in particular, is used to set up and verify trust > relationship). > > Once we implement AD GC service, AD admins will be able to subject IPA > users/hosts to further limit their access to other AD services beyond > simple read-only access to AD LDAP and SMB services. As result, in > future more fine-grained privilege and security separation between AD > and IPA will be possible. > >> >>> Also if external users do not authenticate using Kerberos (for example >>> they always use a special portal) then it does not matter what trust >>> is between AD and IPA because those users will not have kerberos >>> tickets that are leveraged in SSO in trust case. >> >> I want to be able to point either an LDAP or a Kerberos client at IPA, >> and have it authenticate my "enterprise" and "external" users for me. >> I'm not going to tangle with SSO at the moment. Right now, we're just >> establishing an identity store. > That is what provided by IPA's AD trusts. IPA machines can resolve > identities of the users and groups in AD and can authenticate those > users on logons, subject to HBAC policies. > >>> IPA can trust AD. Formally it is a mutual trust but in reality IPA >>> does not have global catalog support for users in IPA to be able to >>> access the resources in AD. >> >> In many of the tutorials/HOWTOs, I see that there is a requirement to >> provide credentials having the permission to add a computer to the >> domain, or being a member of an AD administration group. I'm a lowly >> standard "User" in the AD. I don't know if that means I can add a >> computer to the domain or not. I know I lack the ability to edit AD >> entries that aren't mine, so I really need a solution that does not >> require creating a trust relationship inside AD. > Both AD integration solutions we have (synchronization and cross-forest > domain trusts) assume having higher level access privileges at the time > integration is set up. I'm unaware of other mechanisms that would give > you the same flexibility and level of privilege separation between the > AD and IPA domains. Having a standard 'User' account in AD only entitles > you to join up to 10 machines in AD. These machine will become a part of > AD domain and are subject of their policies which are quite extended by > default. Cross-forest domain trusts, on the other hand, are subject to > inter-domain trust relationship policies which are better constrained. > > One could try to fiddle with AD-joined machine accounts to represent IPA > hosts but it is very much uncharted territory since there will be no > integration whatsoever on any of IPA features (access controls to IPA > services, ID allocation, etc) and everything will need to be set up and > maintained manually, including periodical refreshes of the machine > accounts. In addition, Kerberos authentication will simply not work as > AD has certain assumption over DNS namespace mapping to Kerberos realms. > > >> Is there a way for me to comment out the AD->IPA trust creation, or >> would that break the IPA->AD trust? > The latter, since AD->IPA part of the trust is used to query AD users > and groups. In other words, it is used to provide the key resources > needed to operate IPA->AD trust part. > > The shorter answer is: to setup any integration you need to ask AD admin to help you out to setup t
Re: [Freeipa-users] One way trusts
Hi, On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote: Hi Dimitri, Just to be sure I understand. You have internal users - they are in AD. You have external users - they are in LDAP. You merge two directories and you want to replace this setup with IPA. Yes. It seems that to support your use case you would need to make the external users be IPA users and make AD and IPA trust each other. I think I concur about migrating my external users into IPA and making IPA trust AD. I may be ignorant of some AD nuance, but I do not see why AD needs to trust IPA. AD does not need to trust my LDAP clients currently. IPA needs to be able to look up users and groups in AD. To do so, it uses Kerberos authentication against AD's Global Catalog services with own credentials (per each IPA host). We are using cross-realm Kerberos trust here, AD DC trusts cross-realm TGT issued by IPA KDC and vice versa, so IPA hosts can bind as their own identity (host/...) to AD. Since we don't implement fully all services needed to grant privileges beyond read-only in AD, these binds to AD Global Catalog become read-only. They are still required. An alternative would have been to always keep an account in AD for each IPA host that needs to query user and group identities from AD. We decided to go with the cross-realm Kerberos trust instead since it gives better way of privilege separation. Cross-realm Kerberos trust is known as cross-forest domain trust in AD speak since there are more protocol layers than Kerberos involved (SMB protocol, in particular, is used to set up and verify trust relationship). Once we implement AD GC service, AD admins will be able to subject IPA users/hosts to further limit their access to other AD services beyond simple read-only access to AD LDAP and SMB services. As result, in future more fine-grained privilege and security separation between AD and IPA will be possible. Also if external users do not authenticate using Kerberos (for example they always use a special portal) then it does not matter what trust is between AD and IPA because those users will not have kerberos tickets that are leveraged in SSO in trust case. I want to be able to point either an LDAP or a Kerberos client at IPA, and have it authenticate my "enterprise" and "external" users for me. I'm not going to tangle with SSO at the moment. Right now, we're just establishing an identity store. That is what provided by IPA's AD trusts. IPA machines can resolve identities of the users and groups in AD and can authenticate those users on logons, subject to HBAC policies. IPA can trust AD. Formally it is a mutual trust but in reality IPA does not have global catalog support for users in IPA to be able to access the resources in AD. In many of the tutorials/HOWTOs, I see that there is a requirement to provide credentials having the permission to add a computer to the domain, or being a member of an AD administration group. I'm a lowly standard "User" in the AD. I don't know if that means I can add a computer to the domain or not. I know I lack the ability to edit AD entries that aren't mine, so I really need a solution that does not require creating a trust relationship inside AD. Both AD integration solutions we have (synchronization and cross-forest domain trusts) assume having higher level access privileges at the time integration is set up. I'm unaware of other mechanisms that would give you the same flexibility and level of privilege separation between the AD and IPA domains. Having a standard 'User' account in AD only entitles you to join up to 10 machines in AD. These machine will become a part of AD domain and are subject of their policies which are quite extended by default. Cross-forest domain trusts, on the other hand, are subject to inter-domain trust relationship policies which are better constrained. One could try to fiddle with AD-joined machine accounts to represent IPA hosts but it is very much uncharted territory since there will be no integration whatsoever on any of IPA features (access controls to IPA services, ID allocation, etc) and everything will need to be set up and maintained manually, including periodical refreshes of the machine accounts. In addition, Kerberos authentication will simply not work as AD has certain assumption over DNS namespace mapping to Kerberos realms. Is there a way for me to comment out the AD->IPA trust creation, or would that break the IPA->AD trust? The latter, since AD->IPA part of the trust is used to query AD users and groups. In other words, it is used to provide the key resources needed to operate IPA->AD trust part. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] One way trusts
Hi Dimitri, >Just to be sure I understand. >You have internal users - they are in AD. You have external users - they are >in LDAP. >You merge two directories and you want to replace this setup with IPA. Yes. >It seems that to support your use case you would need to make the external >users be IPA users and make AD and IPA trust each other. I think I concur about migrating my external users into IPA and making IPA trust AD. I may be ignorant of some AD nuance, but I do not see why AD needs to trust IPA. AD does not need to trust my LDAP clients currently. >Also if external users do not authenticate using Kerberos (for example they >always use a special portal) then it does not matter what trust is between AD >and IPA because those users will not have kerberos tickets that are leveraged >in SSO in trust case. I want to be able to point either an LDAP or a Kerberos client at IPA, and have it authenticate my "enterprise" and "external" users for me. I'm not going to tangle with SSO at the moment. Right now, we're just establishing an identity store. >IPA can trust AD. Formally it is a mutual trust but in reality IPA does not >have global catalog support for users in IPA to be able to access the >resources in AD. In many of the tutorials/HOWTOs, I see that there is a requirement to provide credentials having the permission to add a computer to the domain, or being a member of an AD administration group. I'm a lowly standard "User" in the AD. I don't know if that means I can add a computer to the domain or not. I know I lack the ability to edit AD entries that aren't mine, so I really need a solution that does not require creating a trust relationship inside AD. Is there a way for me to comment out the AD->IPA trust creation, or would that break the IPA->AD trust? Thanks much, Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] One way trusts
On 01/13/2014 06:29 PM, Nordgren, Bryce L -FS wrote: > > Hello, > > > > I manage a suite of machines and services which are used for > collaborative projects with external partners. I want to allow users > within our organization to authenticate with their existing Active > Directory accounts, and I have set up an "External Users" LDAP > directory to establish identities for our partners. I have an LDAP > server set up which merges the two directories and which forwards > requests on to the correct directory. > > > > I like the idea of FreeIPA, however, I need support for a one-way > trust. I don't have the ability to modify any entries in our AD > server, but I do have a normal user account (hence I can bind to AD's > LDAP interface). However, I think this is kind of a moot point since > external users should under no circumstances be allowed access to our > internal network/services. Read-only access to AD is just peachy. I > found this old message (June 2012) on your mailing list which suggests > one-way trusts may be on your radar. [1] However, I looked through > your Trac tickets and didn't see any follow up. Did I miss something? > Is this already implemented, or are plans in place? > Just to be sure I understand. You have internal users - they are in AD. You have external users - they are in LDAP. You merge two directories and you want to replace this setup with IPA. IPA can trust AD. Formally it is a mutual trust but in reality IPA does not have global catalog support for users in IPA to be able to access the resources in AD. So it is one way trust due to limited functionality. The global catalog support is being worked on. As soon as it is implemented we will add more granularity to the way the trusts are established and thus allow formal one way trusts. It seems that to support your use case you would need to make the external users be IPA users and make AD and IPA trust each other. Also if external users do not authenticate using Kerberos (for example they always use a special portal) then it does not matter what trust is between AD and IPA because those users will not have kerberos tickets that are leveraged in SSO in trust case. HTH. > > > Thanks much, > > Bryce > > > > [1] https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html > > > > > > This electronic message contains information generated by the USDA > solely for the intended recipients. Any unauthorized interception of > this message or the use or disclosure of the information it contains > may violate the law and subject the violator to civil or criminal > penalties. If you believe you have received this message in error, > please notify the sender and delete the email immediately. > > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] One way trusts
Hello, I manage a suite of machines and services which are used for collaborative projects with external partners. I want to allow users within our organization to authenticate with their existing Active Directory accounts, and I have set up an "External Users" LDAP directory to establish identities for our partners. I have an LDAP server set up which merges the two directories and which forwards requests on to the correct directory. I like the idea of FreeIPA, however, I need support for a one-way trust. I don't have the ability to modify any entries in our AD server, but I do have a normal user account (hence I can bind to AD's LDAP interface). However, I think this is kind of a moot point since external users should under no circumstances be allowed access to our internal network/services. Read-only access to AD is just peachy. I found this old message (June 2012) on your mailing list which suggests one-way trusts may be on your radar. [1] However, I looked through your Trac tickets and didn't see any follow up. Did I miss something? Is this already implemented, or are plans in place? Thanks much, Bryce [1] https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
