Can we see your pam PT configuration? dsconf instance plugins pass-thru show (I think ... I'm going from memory here). Could also be useful to see an example of an adsynced user as well. I've been looking into adsync a bit lately, so I can investigate this further if needed later. -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia

Sure, this is the relative parts. PAM PASS THROUGH dn: cn=PAM Pass Through Auth,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject objectClass: pamConfig cn: PAM Pass Through Auth nsslapd-pluginPath: libpam-passthru-plugin nsslapd-pluginInitfunc: pam_passthruauth_init nsslapd-pluginType: betxnpreoperation nsslapd-pluginEnabled: on nsslapd-pluginloadglobal: true nsslapd-plugin-depends-on-type: database pamMissingSuffix: ALLOW pamExcludeSuffix: cn=config pamIncludeSuffix: ou=Internal Users,ou=people,dc=lab,dc=com pamIDMapMethod: RDN ENTRY pamIDAttr: uid pamFallback: FALSE pamSecure: FALSE pamService: ldapserver nsslapd-pluginId: pam_passthruauth nsslapd-pluginVersion: 1.4.4.11 nsslapd-pluginVendor: 389 Project nsslapd-pluginDescription: PAM pass through authentication plugin modifiersName: cn=directory manager modifyTimestamp: 20211126222824Z dn: cn=Pass Through Authentication,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: Pass Through Authentication nsslapd-pluginPath: libpassthru-plugin nsslapd-pluginInitfunc: passthruauth_init nsslapd-pluginType: preoperation nsslapd-pluginEnabled: off nsslapd-plugin-depends-on-type: database nsslapd-pluginId: none nsslapd-pluginVersion: none nsslapd-pluginVendor: none nsslapd-pluginDescription: none modifiersName: cn=Directory Manager modifyTimestamp: 20211126204904Z WIN AGREEMENT dn: cn=AD2D389,cn=replica,cn=dc\3Dlab\2Cdc\3Dcom,cn=mapping tree,cn=config objectClass: top objectClass: nsDSWindowsReplicationAgreement cn: AD2D389 nsDS5ReplicaRoot: dc=lab,dc=com description: AD2D389 nsDS5ReplicaHost: labdc1.lab.local nsDS5ReplicaPort: 636 nsDS5ReplicaTransportInfo: LDAPS nsDS5ReplicaBindDN: CN=cadroot,CN=Users,DC=lab,DC=local nsds7WindowsReplicaSubtree: CN=D389Sync,DC=lab,DC=local nsds7DirectoryReplicaSubtree: ou=testsync,dc=lab,dc=com nsds7WindowsDomain: lab.local nsds7NewWinUserSyncEnabled: on oneWaySync: fromWindows nsDS5ReplicaCredentials: {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG RERBNEJDUmtOamt6TnpSbE9DMHlZelpsTXpFeA0KT0MwNU5UTXdZMk15WVMxalpUWTNNbVkyTkFBQ 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQ01UWFd2dTBvVVA2L0 h5aE5xNlRhZA==}MzFOFTDpXeukpOmvxtf7fFlWjNB4LlKWM+Ldhzm/Ne4= creatorsName: cn=Directory Manager modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config createTimestamp: 20211130085214Z modifyTimestamp: 20211201203059Z nsds5ReplicaEnabled: on nsds7DirsyncCookie:: TVNEUwMAAABdO7uy8ebXAQAAAAAAAAAAKAAAAP3wAAAAAAAAAAAAAAAAA AD98AAAAAAAAG0xgiTivNBHtESspvYhd58BAAAAAAAAAAEAAAAAAAAAbTGCJOK80Ee0RKym9iF3n/ 3wAAAAAAAA nsds50ruv: {replicageneration} 61a4ddd50000ffff0000 nsds50ruv: {replica 1 ldap://directory389.lab.local:389} 61a5e821000000010000 61a7da69000000010000 nsruvReplicaLastModified: {replica 1 ldap://directory389.lab.local:389} 61a7da 6a EXAMPLE OF AD SYNCED USER(as you can see nsAccount is not present): 36 uid=test.user10,ou=testsync,dc=lab,dc=com objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetOrgPerson objectclass: ntUser ntUserDeleteAccount: true uid: test.user10 sn: User 10 givenName: Test cn: Test User 10 ntUserCodePage: 0 ntUserAcctExpires: 9223372036854775807 ntUserDomainId: test.user10 ntUniqueId: 9658f59ce2a1d54cbeacb783c12a6de3 Once solved this issue, i think it would be better to sync AD user that belongs to specific AD Group in order to have a ore control over it instead of defining a specific OU. I've seen a page wich reports the existence of "Support Filters": https://directory.fedoraproject.org/docs/389ds/design/winsync-rfe.html#2-... And it says: new config parameters in windwows sync agreement: winSyncWindowsFilter: additional_filter_on_AD winSyncDirectoryFilter: additional_filter_on_DS Example: winSyncWindowsFilter: (|(cn=*user*)(cn=*group*)) winSyncDirectoryFilter: (|(uid=*user*)(cn=*group*)) Anyway it is not clear if my installed version support this feature 389-Directory/1.4.4.11 B2021.139.1122 Thanks for your support Appreciate

Hi William, the pam, for users created manually is working fine to me. The only problem is related to synced users from AD whch seems doesn't have all the necessary objectClasses. However, this is ldapserver pam service: # here are the per-package modules (the "Primary" block) auth [success=2 default=ignore] pam_unix.so nullok auth [success=1 default=ignore] pam_sss.so use_first_pass debug # here's the fallback if no module succeeds auth requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around auth required pam_permit.so # and here are more per-package modules (the "Additional" block) # end of pam-auth-update config and this is sssd.con file: [sssd] domains = lab.local config_file_version = 2 services = nss, pam debug_level = 10 [domain/lab.local] default_shell = /bin/bash krb5_store_password_if_offline = True cache_credentials = True krb5_realm = LAB.LOCAL realmd_tags = manages-system joined-with-adcli id_provider = ad fallback_homedir = /home/%u@%d ad_domain = lab.local use_fully_qualified_names = False ldap_id_mapping = True access_provider = ad #enumerate = true auth_provider = ad chpass_provider = ad ldap_schema = ad dyndns_update = true dyndns_refresh_interval = 43200 dyndns_update_ptr = true dyndns_ttl = 3600 Hope to have a soonest reply from you. Best Regards

Thank you for your suggestions. I've got it working after realized that the problem were in AD DN plugin where addn_filter was set to evaluate only nsAccount as objectClass. However your PAM config looks better and i must confess, i am not a PAM guru. I will explore better this topic. Regarding my second question, reported here: i think it would be better to sync AD user that belongs to specific AD Group in order to have more control over it instead of defining a specific OU. I've seen a page which reports the existence of "Support Filters": https://directory.fedoraproject.org/docs/389ds/design/winsync-rfe.html#2-... And it says: new config parameters in windwows sync agreement: winSyncWindowsFilter: additional_filter_on_AD winSyncDirectoryFilter: additional_filter_on_DS Example: winSyncWindowsFilter: (|(cn=*user*)(cn=*group*)) winSyncDirectoryFilter: (|(uid=*user*)(cn=*group*)) Anyway it is not clear if my installed version support this feature 389-Directory/1.4.4.11 B2021.139.1122 Thanks for your support Appreciate

I think it should be supported. https://access.redhat.com/documentation/en-us/red_hat_directory_server/11... You need to create an OR filter that describes the set of users AND groups you want to sync for the "--win-filter" setting in this case. -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia

Unfortunately one thing is still missing in Winsync configuration. Changing the Windows Subtree config, i've noticed that it replicates full DN and if missing in the destination(ex: contained OU in AD), D389 it fails. Just to explain me well. The source AD subtree has become: dc=lab,dc=local The Destination D389 subtree is: ou=Internal Users,ou=people,dc=lab,dc=com Syncing, for example a user like "CN=Test User28,CN=Users,DC=lab,DC=local" from AD to D389, Winsync tries to find destination like "CN=Test User28,cn=users,ou=internal users,ou=people,dc=lab,dc=com" and it fails because in D389 cn=users does not exist. Error example: [09/Dec/2021:16:54:24.989240510 +0100] - ERR - NSMMReplicationPlugin - windows sync - windows_update_local_entry - Failed to rename entry ("uid=test.user28,ou=Internal Users,ou=people,dc=lab,dc=com"); LDAP error - 32 (newrdn: "uid=test.user28", newsuperior: "cn=users,ou=internal users,ou=people,dc=lab,dc=com" [09/Dec/2021:16:54:25.006162407 +0100] - DEBUG - NSMMReplicationPlugin - windows sync - windows_process_dirsync_entry - agmt="cn=AD2D389" (labdc1:636) - Failed to update inbound entry for CN=Test User 28,CN=D389Sync,DC=lab,DC=local. Is there any way to replicate only the relative parts without searching for a full DN? or Can Winsync create/replicate missing Ous or containers? What am i missing? Many Thanks

Ok reported on GitHub, hope someone could make a step further on this. Many Thanks