#2907 Add option to specify custom sAMAccountName in sssd-ad
Closed: Duplicate None Opened 8 years ago by punisherhd.

Hello, I'm using SSSD-AD on RHEL 6.7 in a Windows 2012 R2 domain.
I'm using the GPO stuff too for access control policies.

I have specific clients computers which are manually created in the Windows domain, and which have a custom sAMAccountName attribute value.
E.g. by default, the sAMAccountName is equal to the uppercase hostname (without domain) plus a dollar sign.
This is what SSSD expects, as we can see in 'ad_gpo.c'.

But in my case, this is incorrect. I manually set the computer's sAMAccountName to a custom value in the Active Directory. So I need a way to specify this value in my SSSD configuration.

For example having a new option 'ad_samaccountname' that could overwrite the default value. It would look like:


[domain/mydomain.org]
id_provider=ad
.....
ad_hostname = computer1.mycompany.org
ad_samaccountname = CPT1$


If the option is not specified, then the current behaviour should be kept.


You can already override it with configure option ldap_sasl_authid. @see more details in man sssd-ldap

cc: => lslebodn@redhat.com

Hello, the manual page says that ldap_sasl_authid represents the Kerberos principal name of the host, not the SAM account name ...
Even though they can have a similar value 99% of the time, they may be different, as in my scenario.

On the LDAP side, I have a computer record with following attributes:

name = COMPUTER1
dNSHostName = computer1.domain.com
servicePrincipalName = HOST/computer1.domain.com
userPrincipalName = HOST/computer1.domain.com@DOMAIN.COM
sAMAccountName = CPT1$

In an usual scenario, the sAMAccountName would have value "COMPUTER1$", but this it not the case here.

From what I understand about SSSD, the variables in sssd.conf matches the LDAP attribute as follow:

ad_hostname => dNSHostName
ldap_sasl_authid = ServicePrincipalName | userPrincipalName

So, I'm still stuck here.

I think that either the GPO related code should locate the GPO for this computer using SPN/UPN instead of sAMAccountName, or SSSD should let me specify manually the sAMAccountName in its configuration file.

Replying to [comment:2 punisherhd]:

Hello, the manual page says that ldap_sasl_authid represents the Kerberos principal name of the host, not the SAM account name ...
Even though they can have a similar value 99% of the time, they may be different, as in my scenario.

On the LDAP side, I have a computer record with following attributes:
{{{
name = COMPUTER1
dNSHostName = computer1.domain.com
servicePrincipalName = HOST/computer1.domain.com
userPrincipalName = HOST/computer1.domain.com@DOMAIN.COM
sAMAccountName = CPT1$
}}}
In an usual scenario, the sAMAccountName would have value "COMPUTER1$", but this it not the case here.

From what I understand about SSSD, the variables in sssd.conf matches the LDAP attribute as follow:
{{{
ad_hostname => dNSHostName
ldap_sasl_authid = ServicePrincipalName | userPrincipalName
}}}
For active directory, ldap_sasl_authid is extracted from used principal from keytab.
So you probably have following principal in keytab:

CPT1$@DOMAIN.COM
HOST/computer1.domain.com@DOMAIN.COM

You can use klist -kt to be sure.
So it's possible that wrong principal was used by sssd
therefore GPO needn't work

So, I'm still stuck here.

I think that either the GPO related code should locate the GPO for this computer using SPN/UPN instead of sAMAccountName, or SSSD should let me specify manually the sAMAccountName in its configuration file.

I would say you might misinterpreted some messages in sssd log files.

I think it would be good If you could provide output of "klist -kt", and domain log files with high debug_level (9) and sssd configuration file

Output for command 'ktlist -kt'
ktlist-kt.log

Hello, I've uploaded the requested files.

Please note that my keytab contains only a single entry "HOST/computer1.domain.com@DOMAIN.COM". (I create the keytab files manually using ktutil). In your previous post you mention that it should contain 2 entries, this may be a starter for my problem. I will try to add a 2nd entry with "CPT1$@DOMAIN.COM" as you suggested.

About the log files, what brings my attention is line 1503:

[sssd[be[domain.com]]] [ad_gpo_connect_done] (0x0400): sam_account_name is COMPUTER1$

So I believe this is where the problem begins. The value COMPUTER1$ is derivated from the hostname.
See: https://git.fedorahosted.org/cgit/sssd.git/tree/src/providers/ad/ad_gpo.c?h=sssd-1_12_4 line 1707

Just below, line 1505, we can see an LDAP query using the sAMAccountName:
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=user) (sAMAccountName=COMPUTER1$))][dc=domain,dc=com].

And it doesn't find anything in Active Directory, because sAMAccountName has a different value (CPT1$) ...

BTW, why are we looking for the host record using sAMAccountName, and not the SPN or UPN ? Everything except the GPO seems to work OK with my configuration ...

Replying to [comment:4 punisherhd]:

Hello, I've uploaded the requested files.

Please note that my keytab contains only a single entry "HOST/computer1.domain.com@DOMAIN.COM". (I create the keytab files manually using ktutil). In your previous post you mention that it should contain 2 entries, this may be a starter for my problem. I will try to add a 2nd entry with "CPT1$@DOMAIN.COM" as you suggested.

It will help but it would not be enough. Because sssd would still try to find COPUTER1$DOMAIN.COM in keytab.
You can already see it in log file

[sdap_set_sasl_options] (0x0100): Will look for computer1.domain.com@DOMAIN.COM in default keytab 
[select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab 
[find_principal_in_keytab] (0x4000): Trying to find principal computer1.domain.com@DOMAIN.COM in keytab.
[find_principal_in_keytab] (0x0400): No principal matching computer1.domain.com@DOMAIN.COM found in keytab.
[find_principal_in_keytab] (0x4000): Trying to find principal COMPUTER1$@DOMAIN.COM in keytab.
[find_principal_in_keytab] (0x0400): No principal matching COMPUTER1$@DOMAIN.COM found in keytab.
[find_principal_in_keytab] (0x4000): Trying to find principal HOST/computer1.domain.com@DOMAIN.COM in keytab.
[match_principal] (0x1000): Principal matched to the sample (HOST/computer1.domain.com@DOMAIN.COM).
[select_principal_from_keytab] (0x0200): Selected primary: HOST/computer1.domain.com
[select_principal_from_keytab] (0x0200): Selected realm: DOMAIN.COM

But it's not a problem because you needn't rely on auto-detecting ldap_sasl_authid from keytab.
So please also set ldap_sasl_authid = CPT1$@DOMAIN.COM or just to CPT1$

It should also work if you set to wrong value becuase sssd witt not be able find principal host/wrong_value@DOMAIN.COM and fall back to find principals with "$"

[find_principal_in_keytab] (0x4000): Trying to find principal *$@SSSDAD.COM in keytab.
[match_principal] (0x1000): Principal matched to the sample (*$@SSSDAD.COM).
[select_principal_from_keytab] (0x0200): Selected primary: HP-DL380PGEN8-0$
[select_principal_from_keytab] (0x0200): Selected realm: SSSDAD.CO

About the log files, what brings my attention is line 1503:
{{{
[sssd[be[domain.com]]] [ad_gpo_connect_done] (0x0400): sam_account_name is COMPUTER1$
}}}
So I believe this is where the problem begins. The value COMPUTER1$ is derivated from the hostname.
See: https://git.fedorahosted.org/cgit/sssd.git/tree/src/providers/ad/ad_gpo.c?h=sssd-1_12_4 line 1707

It was changed in sssd-1.13.1. That's the reason why I could not reproduce it. And it's the same reason why I mentioned ldap_sasl_authid. More details in ticket #2692
or commit
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=560b624b34895df55bf489a1d53380c6c8c82e03

Just below, line 1505, we can see an LDAP query using the sAMAccountName:
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=user) (sAMAccountName=COMPUTER1$))][dc=domain,dc=com].

And it userPrincipalNamedoesn't find anything in Active Directory, because sAMAccountName has a different value (CPT1$) ...

BTW, why are we looking for the host record using sAMAccountName, and not the SPN or UPN ? Everything except the GPO seems to work OK with my configuration ...

It might be explained by missing attribute userPrincipalName for computers in Active directory (ldap entries with objectClass = computer)

I have only SPN for my hosts. I tried to join machines with "net ads join" (samba tools) and "realm join" (realmd)
e.g.

servicePrincipalName: HOST/hp-dl380pgen8-0.sssdad.com
servicePrincipalName: HOST/HP-DL380PGEN8-0

So you cannot use ldap_sasl_authid on rhel6.7 to override default behaviour. If you have a Red Hat subscription then you might ask to back-port ticket #2692 to rhel6.7

Or you might use backported versions from fedora (upstream versions of sssd)
https://copr.fedoraproject.org/coprs/g/sssd/sssd-1-13/
or preview of sssd in rhel6.8
https://copr.fedoraproject.org/coprs/jhrozek/SSSD-6.8-preview/

Thanks for your help, I will open a ticket on RHEL web site.

Still, I don't understand why the GPO code uses the sAMAccountName attribute to locate the computer in LDAP, and not the SPN (which always has same value in LDAP and /etc/krb5.keytab).
Except for the GPO, all features (user authentication, kerberos password change ...) work fine with my current setup, so I bet nothing else in SSSD uses the sAMAccountName ...

If I understand it correctly it works for you with sssd-1.13.1+.

So I will close the ticket as duplicate of #2692

resolution: => duplicate
status: new => closed

Replying to [comment:7 punisherhd]:

Thanks for your help, I will open a ticket on RHEL web site.

Still, I don't understand why the GPO code uses the sAMAccountName attribute to locate the computer in LDAP, and not the SPN (which always has same value in LDAP and /etc/krb5.keytab).
Except for the GPO, all features (user authentication, kerberos password change ...) work fine with my current setup, so I bet nothing else in SSSD uses the sAMAccountName ...

The sAMAccountName is used by AD to derive the user-principal-name (UPN) for the host. Typically the UPN looks like hostname$@AD.DOMAIN and only this name can be used to get a Kerberos TGT with kinit.

The service principals (SPN) can only be used for service tickets. kinit with one of the SPN will in general not work. These service principals can be added or removed depending on which services should be provided by the client. E.g. host/... is used for terminal access w.g. eith ssh, cifs/.... for file-system access, ldap/... if the host provides an LDAP service (think of a AD DC), HTTP/.... for web-servers. It is up to the utility which joins the client to the domain which SPNs are created initially and they can be modified at will at runtime.

So the sAMAcountName is a better unique identifier for a host and since SSSD use the host UPN the get the initial TGT which is required to get authenticated access to the AD LDAP service we can expect that the host entry can be looked up with this name as well.

Metadata Update from @punisherhd:
- Issue set to the milestone: NEEDS_TRIAGE

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3948

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata