Hi list-
I'm working on a project using Active Directory 2008 R2 with Identity Management for UNIX service to provide authentication and identity for Linux users via sssd.
Using this setup, is it possible to have the Linux username and group name be the same (e.g. user apache, group apache)? I've learned that the sAMAccountName attribute must be unique across the domain but I'm not sure if sssd uses this attribute to "translate" the UID and GID to names in Linux. Hope this makes sense!
Our sssd.conf is:
[sssd] config_file_version = 2 debug_level = 0 domains = example.com services = nss, pam [domain/example.com] id_provider = ad access_provider = ad # We rely on UNIX extended attributes in AD ldap_id_mapping = false enumerate = true
--
Andre Pitanga RHCE 100-077-478 (917) 745-6256 andre.pitanga@redhat.com Red Hat, Inc. Red Hat Consulting
On Fri, Aug 22, 2014 at 09:23:40AM -0400, Andre Pitanga wrote:
Hi list-
I'm working on a project using Active Directory 2008 R2 with Identity Management for UNIX service to provide authentication and identity for Linux users via sssd.
Using this setup, is it possible to have the Linux username and group name be the same (e.g. user apache, group apache)? I've learned that the sAMAccountName attribute must be unique across the domain but I'm not sure if sssd uses this attribute to "translate" the UID and GID to names in Linux. Hope this makes sense!
Our sssd.conf is:
[sssd] config_file_version = 2 debug_level = 0 domains = example.com services = nss, pam [domain/example.com] id_provider = ad access_provider = ad # We rely on UNIX extended attributes in AD ldap_id_mapping = false enumerate = true
The group names should be OK for primary domain, but might be problematic in a trusted domain.
I would recommend to remove enumerate=true from the config file, too.
----- Original Message ----- From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-users@lists.fedorahosted.org Sent: Monday, August 25, 2014 4:29:16 AM Subject: Re: [SSSD-users] Same user name and group name in AD
The group names should be OK for primary domain, but might be problematic in a trusted domain.
Thanks, Jakub. Will take this in consideration. Any further info on this appreciated.
I would recommend to remove enumerate=true from the config file, too.
Yep, just there during development.
Best, -AP
On 22/08/14 14:23, Andre Pitanga wrote:
Hi list-
I'm working on a project using Active Directory 2008 R2 with Identity Management for UNIX service to provide authentication and identity for Linux users via sssd.
Using this setup, is it possible to have the Linux username and group name be the same (e.g. user apache, group apache)?
You cannot have a 'user' object and a 'group' object with the same name, further more, the example you give is a 'local unix' user and should not be put into AD. If you did put them into AD, you would have to remove them from /etc/passwd and if the domain went down for some reason, you would have NO USERS at all.
If you are going to use AD, then I suggest that you do a bit more research, it will not work the way you want it to, this has nothing to do with sssd.
Rowland
I've learned that the sAMAccountName attribute must be unique across the domain but I'm not sure if sssd uses this attribute to "translate" the UID and GID to names in Linux. Hope this makes sense!
Our sssd.conf is:
[sssd] config_file_version = 2 debug_level = 0 domains = example.com services = nss, pam [domain/example.com] id_provider = ad access_provider = ad # We rely on UNIX extended attributes in AD ldap_id_mapping = false enumerate = true
--
Andre Pitanga RHCE 100-077-478 (917) 745-6256 andre.pitanga@redhat.com Red Hat, Inc. Red Hat Consulting
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi Rowland,
You cannot have a 'user' object and a 'group' object with the same name,
I know that, that's what I pose in my original post if you read it. The sAMAccountName has to be unique, but this doesn't seem to apply to disply name, for example.
further more, the example you give is a 'local unix' user and should not be put into AD. If you did put them into AD, you would have to remove them from /etc/passwd and if the domain went down for some reason, you would have NO USERS at all.
So what? Does sssd not provide local credentials caching? Isn't AD fault-tolerant/ highly-available across several hosts? Housing Linux "service accounts" in AD is a very common practice.
If you are going to use AD, then I suggest that you do a bit more research, it will not work the way you want it to, this has nothing to do with sssd.
Based on your response it would seem this advice applies more to yourself : )
-AP
On 25/08/14 13:44, Andre Pitanga wrote:
Hi Rowland,
You cannot have a 'user' object and a 'group' object with the same name,
I know that, that's what I pose in my original post if you read it. The sAMAccountName has to be unique, but this doesn't seem to apply to disply name, for example.
Yes, I did read it, so 'display name' doesn't have to be unique, so what, does anything actually use this attribute in authentication ?
further more, the example you give is a 'local unix' user and should not be put into AD. If you did put them into AD, you would have to remove them from /etc/passwd and if the domain went down for some reason, you would have NO USERS at all.
So what? Does sssd not provide local credentials caching? Isn't AD fault-tolerant/ highly-available across several hosts? Housing Linux "service accounts" in AD is a very common practice.
Yes, sssd does provide caching, but what happens if the cache gets corrupt ? Yes AD is fault tolerant but I still think it is a bad idea to put Linux 'service accounts' into AD and as for 'housing' them in AD being a common practice, I personally have never heard of it.
If you are going to use AD, then I suggest that you do a bit more research, it will not work the way you want it to, this has nothing to do with sssd.
Based on your response it would seem this advice applies more to yourself : )
No, I am a practical person and do my research and will not do anything stupid in production, you might want to, but I cannot advise it.
Rowland
-AP
On (25/08/14 14:12), Rowland Penny wrote:
On 25/08/14 13:44, Andre Pitanga wrote:
Hi Rowland,
You cannot have a 'user' object and a 'group' object with the same name,
I know that, that's what I pose in my original post if you read it. The sAMAccountName has to be unique, but this doesn't seem to apply to disply name, for example.
Yes, I did read it, so 'display name' doesn't have to be unique, so what, does anything actually use this attribute in authentication ?
further more, the example you give is a 'local unix' user and should not be put into AD. If you did put them into AD, you would have to remove them from /etc/passwd and if the domain went down for some reason, you would have NO USERS at all.
So what? Does sssd not provide local credentials caching? Isn't AD fault-tolerant/ highly-available across several hosts? Housing Linux "service accounts" in AD is a very common practice.
Yes, sssd does provide caching, but what happens if the cache gets corrupt ?
This should never happen. If you see corrupted cache please report immediatelly. I am not aware of any bug with corupted cache.
LS
On 25/08/14 14:29, Lukas Slebodnik wrote:
On (25/08/14 14:12), Rowland Penny wrote:
On 25/08/14 13:44, Andre Pitanga wrote:
Hi Rowland,
You cannot have a 'user' object and a 'group' object with the same name,
I know that, that's what I pose in my original post if you read it. The sAMAccountName has to be unique, but this doesn't seem to apply to disply name, for example.
Yes, I did read it, so 'display name' doesn't have to be unique, so what, does anything actually use this attribute in authentication ?
further more, the example you give is a 'local unix' user and should not be put into AD. If you did put them into AD, you would have to remove them from /etc/passwd and if the domain went down for some reason, you would have NO USERS at all.
So what? Does sssd not provide local credentials caching? Isn't AD fault-tolerant/ highly-available across several hosts? Housing Linux "service accounts" in AD is a very common practice.
Yes, sssd does provide caching, but what happens if the cache gets corrupt ?
This should never happen. If you see corrupted cache please report immediatelly. I am not aware of any bug with corupted cache.
I never said it would happen, I just said what if it did. Do not say it will never happen, because anything that can go wrong, will go wrong, it is just the nature of things.
Rowland
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, 2014-08-25 at 14:12 +0100, Rowland Penny wrote:
On 25/08/14 13:44, Andre Pitanga wrote:
If you are going to use AD, then I suggest that you do a bit more research, it will not work the way you want it to, this has nothing to do with sssd.
Based on your response it would seem this advice applies more to yourself : )
No, I am a practical person and do my research and will not do anything stupid in production, you might want to, but I cannot advise it.
People please, let's keep a professional tone, name-calling will not be tolerated.
Simo.
sssd-users@lists.fedorahosted.org
-
Andre Pitanga -
Jakub Hrozek -
Lukas Slebodnik -
Rowland Penny -
Simo Sorce