Hi all,
I will be doing a short presentation in our company about IPA & sssd & Active Directory. The aim is to motivate headquarters to replace our existing commercial (Centrify) solution with SSSD. The presentation is available at:
http://ulozto.cz/xWxcUab/unixad-pdf
should you like to see it.
Comments are welcome :-) Ondrej
On 08/15/2012 09:12 AM, Ondrej Valousek wrote:
Hi all,
I will be doing a short presentation in our company about IPA & sssd & Active Directory. The aim is to motivate headquarters to replace our existing commercial (Centrify) solution with SSSD. The presentation is available at:
http://ulozto.cz/xWxcUab/unixad-pdf
should you like to see it.
Comments are welcome :-)
1) IPA is based on the 389 LDAP server not OpenLDAP 2) SSSD does not provide front end to Samba/Winbind it just has similar functionality. In future we might reuse more of the samba libraries. Currently we use some samba libraries in SSSD but more as building blocks for the solution than the back end that connects to AD. 3) There is a project called reamld, this project would perform AD join of SSSD in the Linux environment. It will replace the need for your sss_adjoin script 4) Can you please elaborate a bit on the tools? Which tools Centrify has that would be useful for SSSD to have? Can you file tickets with those? 5) In addition to direct automounter support in SSSD there is also direct sudo support, management of the SSH keys and SELinux user mapping integration coming at the same time. 6) I do not think you emphasize the value of IPA. If you are AD centric then joining systems directly to AD makes sense but if you want to mange your Linux environment independently then FreeIPA comes to play as a management server for Linux systems. This brings the question of the AD users. If you want to use central server to manage Linux systems but users to come from AD there are three options that you can explore: * Sync users from AD to IPA. This is currently supported and recommended solution though it has some complications because all user passwords need to be reset once for password sync to happen * Use a "split brain" configuration where the Linux systems are joined to IPA and are controlled by IPA but the user authentication is pointed directly to AD. This is a possible but not recommended configuration as we would not be able to support upgrades from it so an upgrade might break things and things would have to be reconfigured manually. This can be mitigated by testing upgrades first but it is still a not preferred solution. * Trust based solution. AD users stay in AD. Systems are joined into IPA. There is a trust established between IPA and AD. The users from AD then would be able to access systems and services in IPA domain without any synchronization. This is a recommended solution and it is coming soon (upstream bits are in beta now and will be release this fall). The only catch is that both clients (SSSD) and server (IPA) need to support trust capabilities which means latest version of OS will be required on both sides.
Ondrej
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 08/15/2012 03:49 PM, Dmitri Pal wrote:
On 08/15/2012 09:12 AM, Ondrej Valousek wrote:
Hi all,
I will be doing a short presentation in our company about IPA & sssd & Active Directory. The aim is to motivate headquarters to replace our existing commercial (Centrify) solution with SSSD. The presentation is available at:
http://ulozto.cz/xWxcUab/unixad-pdf
should you like to see it.
Comments are welcome :-)
SSSD stands for System Security Services Daemon.
- There is a project called reamld, this project would perform AD join
of SSSD in the Linux environment. It will replace the need for your sss_adjoin script
Just to clarify - the correct spelling is realmd.
Regards, Pavel.
On 08/15/2012 09:49 AM, Dmitri Pal wrote:
On 08/15/2012 09:12 AM, Ondrej Valousek wrote:
Hi all,
I will be doing a short presentation in our company about IPA & sssd & Active Directory. The aim is to motivate headquarters to replace our existing commercial (Centrify) solution with SSSD. The presentation is available at:
http://ulozto.cz/xWxcUab/unixad-pdf
should you like to see it.
Comments are welcome :-)
- IPA is based on the 389 LDAP server not OpenLDAP
- SSSD does not provide front end to Samba/Winbind it just has
similar functionality. In future we might reuse more of the samba libraries. Currently we use some samba libraries in SSSD but more as building blocks for the solution than the back end that connects to AD. 3) There is a project called reamld, this project would perform AD join of SSSD in the Linux environment. It will replace the need for your sss_adjoin script 4) Can you please elaborate a bit on the tools? Which tools Centrify has that would be useful for SSSD to have? Can you file tickets with those? 5) In addition to direct automounter support in SSSD there is also direct sudo support, management of the SSH keys and SELinux user mapping integration coming at the same time. 6) I do not think you emphasize the value of IPA. If you are AD centric then joining systems directly to AD makes sense but if you want to mange your Linux environment independently then FreeIPA comes to play as a management server for Linux systems. This brings the question of the AD users. If you want to use central server to manage Linux systems but users to come from AD there are three options that you can explore:
- Sync users from AD to IPA. This is currently supported and
recommended solution though it has some complications because all user passwords need to be reset once for password sync to happen
- Use a "split brain" configuration where the Linux systems are joined
to IPA and are controlled by IPA but the user authentication is pointed directly to AD. This is a possible but not recommended configuration as we would not be able to support upgrades from it so an upgrade might break things and things would have to be reconfigured manually. This can be mitigated by testing upgrades first but it is still a not preferred solution.
- Trust based solution. AD users stay in AD. Systems are joined into
IPA. There is a trust established between IPA and AD. The users from AD then would be able to access systems and services in IPA domain without any synchronization. This is a recommended solution and it is coming soon (upstream bits are in beta now and will be release this fall). The only catch is that both clients (SSSD) and server (IPA) need to support trust capabilities which means latest version of OS will be required on both sides.
Also you mentioned DNS sites, https://fedorahosted.org/sssd/ticket/1032 Is it required or the notion of the primary and secondary servers that was added in 1.9 sufficiently addresses the issue?
Ondrej
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Thank you, Dmitri Pal
Sr. Engineering Manager for IdM portfolio Red Hat Inc.
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
- IPA is based on the 389 LDAP server not OpenLDAP
Ok.
- SSSD does not provide front end to Samba/Winbind it just has similar functionality. In future we might reuse more of the samba
libraries. Currently we use some samba libraries in SSSD but more as building blocks for the solution than the back end that connects to AD.
I see.
- There is a project called reamld, this project would perform AD join of SSSD in the Linux environment. It will replace the need for
your sss_adjoin script
Thanks for the info. Unfortunately this project did not find its way into RHEL 6 so we can not use it. But I will mention it on my presentation
- Can you please elaborate a bit on the tools? Which tools Centrify has that would be useful for SSSD to have? Can you file tickets with
those?
The tools we would welcome the most would be: *adflush* - flush all databases, force reload all data from ldap servers. Right now I have to stop sssd, delete all ldb files and start sssd again - this is a bit cruel. *adinfo* - tell the user is there is some working connection to any ldap server or whether we are running completely in the disconnected mode. Right now I have to dig through the logs to find out. I think both have been discussed here, but the idea was eventually abandoned by the sssd developers
- In addition to direct automounter support in SSSD there is also direct sudo support, management of the SSH keys and SELinux user
mapping integration coming at the same time.
I will mention that.
- I do not think you emphasize the value of IPA.
True. This was on purpose because my main objective is get something we already have (Centrify) cheaper & better. I understand that using IPA would give us further benefits, but this is out of my current scope.
Also you mentioned DNS sites, https://fedorahosted.org/sssd/ticket/1032 Is it required or the notion of the primary and secondary servers that was added in 1.9 sufficiently addresses the issue?
This ticket was actually created by me and I see that the solution for this one has been deferred :-( . Primary & secondary servers support in 1.9 will not help us as we need a true sites support as per the ticket above. I believe it would be useful for large IPA domains, too.
Many thanks Ondrej
On 08/15/2012 10:19 AM, Ondrej Valousek wrote:
- IPA is based on the 389 LDAP server not OpenLDAP
Ok.
- SSSD does not provide front end to Samba/Winbind it just has
similar functionality. In future we might reuse more of the samba libraries. Currently we use some samba libraries in SSSD but more as building blocks for the solution than the back end that connects to AD.
I see.
- There is a project called reamld, this project would perform AD
join of SSSD in the Linux environment. It will replace the need for your sss_adjoin script
Thanks for the info. Unfortunately this project did not find its way into RHEL 6 so we can not use it. But I will mention it on my presentation
- Can you please elaborate a bit on the tools? Which tools Centrify
has that would be useful for SSSD to have? Can you file tickets with those?
The tools we would welcome the most would be: *adflush* - flush all databases, force reload all data from ldap servers. Right now I have to stop sssd, delete all ldb files and start sssd again - this is a bit cruel.
There is a cache management utility now. Have you looked at it? Is there any functionality missing there?
*adinfo* - tell the user is there is some working connection to any ldap server or whether we are running completely in the disconnected mode. Right now I have to dig through the logs to find out. I think both have been discussed here, but the idea was eventually abandoned by the sssd developers
Yes I agree having a way to dump current status of the SSSD responders and providers would be a nice to have. But it is not quite simple. I think we have a ticket for this. See some thoughts that Stephen recorded there: https://fedorahosted.org/sssd/ticket/385#comment:12
- In addition to direct automounter support in SSSD there is also
direct sudo support, management of the SSH keys and SELinux user mapping integration coming at the same time.
I will mention that.
- I do not think you emphasize the value of IPA.
True. This was on purpose because my main objective is get something we already have (Centrify) cheaper & better. I understand that using IPA would give us further benefits, but this is out of my current scope.
Also you mentioned DNS sites, https://fedorahosted.org/sssd/ticket/1032 Is it required or the notion of the primary and secondary servers that was added in 1.9 sufficiently addresses the issue?
This ticket was actually created by me and I see that the solution for this one has been deferred :-( . Primary & secondary servers support in 1.9 will not help us as we need a true sites support as per the ticket above. I believe it would be useful for large IPA domains, too.
I see. Can you please add a comment to the ticket explaining why the preferred server support is not sufficient and the support of sites is required.
Many thanks Ondrej
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, Aug 15, 2012 at 11:16:10AM -0400, Dmitri Pal wrote:
*adinfo* - tell the user is there is some working connection to any ldap server or whether we are running completely in the disconnected mode. Right now I have to dig through the logs to find out. I think both have been discussed here, but the idea was eventually abandoned by the sssd developers
Yes I agree having a way to dump current status of the SSSD responders and providers would be a nice to have. But it is not quite simple. I think we have a ticket for this. See some thoughts that Stephen recorded there: https://fedorahosted.org/sssd/ticket/385#comment:12
Would something as simple as logging changes to online/offline status to syslog with a lower severity (LOG_INFO or LOG_DEBUG) be useful?
Recent systemd versions also print the last couple of lines that the service logged when "service foo status" (aka systemctl status foo.service) is called.
Then calling "service sssd status" would be able to tell you the last status change of the provider.
On 08/15/2012 11:31 AM, Jakub Hrozek wrote:
On Wed, Aug 15, 2012 at 11:16:10AM -0400, Dmitri Pal wrote:
*adinfo* - tell the user is there is some working connection to any ldap server or whether we are running completely in the disconnected mode. Right now I have to dig through the logs to find out. I think both have been discussed here, but the idea was eventually abandoned by the sssd developers
Yes I agree having a way to dump current status of the SSSD responders and providers would be a nice to have. But it is not quite simple. I think we have a ticket for this. See some thoughts that Stephen recorded there: https://fedorahosted.org/sssd/ticket/385#comment:12
Would something as simple as logging changes to online/offline status to syslog with a lower severity (LOG_INFO or LOG_DEBUG) be useful?
Recent systemd versions also print the last couple of lines that the service logged when "service foo status" (aka systemctl status foo.service) is called.
Then calling "service sssd status" would be able to tell you the last status change of the provider.
Do you plan to issue a message per provider per domain? In this case you might end up with multiple messages.
Can status command support arguments like: service sssd status --domain=ipa --provider=id or service sssd status --domain=ad --provider=pwd_change
Then we can have one message per domain per provider.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, Aug 15, 2012 at 12:36:31PM -0400, Dmitri Pal wrote:
On 08/15/2012 11:31 AM, Jakub Hrozek wrote:
On Wed, Aug 15, 2012 at 11:16:10AM -0400, Dmitri Pal wrote:
*adinfo* - tell the user is there is some working connection to any ldap server or whether we are running completely in the disconnected mode. Right now I have to dig through the logs to find out. I think both have been discussed here, but the idea was eventually abandoned by the sssd developers
Yes I agree having a way to dump current status of the SSSD responders and providers would be a nice to have. But it is not quite simple. I think we have a ticket for this. See some thoughts that Stephen recorded there: https://fedorahosted.org/sssd/ticket/385#comment:12
Would something as simple as logging changes to online/offline status to syslog with a lower severity (LOG_INFO or LOG_DEBUG) be useful?
Recent systemd versions also print the last couple of lines that the service logged when "service foo status" (aka systemctl status foo.service) is called.
Then calling "service sssd status" would be able to tell you the last status change of the provider.
Do you plan to issue a message per provider per domain? In this case you might end up with multiple messages.
Yes, I was thinking a message per provider. That might get verbose in a multi-domain environment, but I don't suspect there would be many setups with many domains, even in an AD-trust setup.
Can status command support arguments like: service sssd status --domain=ipa --provider=id or service sssd status --domain=ad --provider=pwd_change
Then we can have one message per domain per provider.
service is just a wrapper around systemctl from systemd, we don't control it.
There is a cache management utility now. Have you looked at it? Is there any functionality missing there?
I was not aware of the sssd-tools package (not installed by default) - thanks, that solves my requirement.
Yes I agree having a way to dump current status of the SSSD responders and providers would be a nice to have. But it is not quite simple. I think we have a ticket for this. See some thoughts that Stephen recorded there: https://fedorahosted.org/sssd/ticket/385#comment:12
I have just updated this ticket with my thoughts
I see. Can you please add a comment to the ticket explaining why the preferred server support is not sufficient and the support of sites is required.
I have updated the ticket 1032 too.
I really appreciate you lads try to be helpful. Many thanks! Ondrej
On Thu, 2012-08-16 at 09:32 +0200, Ondrej Valousek wrote:
There is a cache management utility now. Have you looked at it? Is there any functionality missing there?
I was not aware of the sssd-tools package (not installed by default) - thanks, that solves my requirement.
I've been thinking about this lately. Given the utility of sss_cache on so many systems, it might be in our best interest to move it out of the sssd-tools subpackage and into the main sssd package.
What do you think, Jakub?
On Thu, Aug 16, 2012 at 07:50:16AM -0400, Stephen Gallagher wrote:
On Thu, 2012-08-16 at 09:32 +0200, Ondrej Valousek wrote:
There is a cache management utility now. Have you looked at it? Is there any functionality missing there?
I was not aware of the sssd-tools package (not installed by default) - thanks, that solves my requirement.
I've been thinking about this lately. Given the utility of sss_cache on so many systems, it might be in our best interest to move it out of the sssd-tools subpackage and into the main sssd package.
What do you think, Jakub?
I agree, I think we should also move sss_debuglevel.
Then the sss-tools subpackage would consist of tools that are either specialized (sss_seed), deal with the local domain (sss_user_*, sss_group_*), or are downright obscure (sss_obfusacte).
sssd-users@lists.fedorahosted.org