nss: use strrchr() instead of strchr() to get the last occurrence of "@"
Subsystems (2)
PATCH 1/1 nss: use strrchr() instead of strchr() to get the last occurrence of "@"
Issues with AD/IPA Trust works & how SSSD deals with AD users.
Lets say we have a IPA domain linux.example.com & AD domain win.example.com, We setup IPA/AD trust so that Windows domain users can login into Linux, When we setup AD Trust with IPA, AD users login as username@AD_REALM, With our example above, username will be "[email protected]" Without @win.example.com that user will be searched only in IPA domain not in AD domain. That is the reason @DOMAIN part is important in SSSD when dealing with IPA-AD trust.
With current behaviour the client-side code is stripping the domain off based on the location of the first "@" character in the value returned by the server. This results in UID/GID mappings failing and resulting in ownership on the clients as "nobody".
With the provided patch, we can accept fully qualified usernames.
commit 7ff76ddf2e37d595732d9c8e534de8aa530eb57a
Author: Shijoe Panjikkaran <[email protected]> Date: Tue Apr 1 20:53:54 2014 +0530
nss: strrchr() instead of strchr() to get the last occurrence of "@"
nss.c +1 -1
@@ -135,7 +135,7 @@ static char *strip_domain(const char *name, const char *domain)char *l =NULL ;int len; - c =strchr (name,'@' ); + c =strrchr (name,'@' );if (c ==NULL && domain !=NULL ) goto out;if (c ==NULL && domain ==NULL ) {
Quoted 7 lines · Shijoe George
Issues with AD/IPA Trust works & how SSSD deals with AD users.
Lets say we have a IPA domain linux.example.com & AD domain win.example.com, We setup IPA/AD trust so that Windows domain users can login into Linux, When we setup AD Trust with IPA, AD users login as username@AD_REALM, With our example above, username will be "[email protected]" Without @win.example.com that user will be searched only in IPA domain not in AD domain. That is the reason @DOMAIN part is important in SSSD when dealing with IPA-AD trust.
With current behaviour the client-side code is stripping the domain off based on the location of the first "@" character in the value returned by the server. This results in UID/GID mappings failing and resulting in ownership on the clients as "nobody".
With the provided patch, we can accept fully qualified usernames.
Committed...
steved.