Hello, I have seen Fedora Directory Server console has support for "NT User" attributes when creating a new user in the directory. However, it seems the enabling the "NT User" capability uses an objectclass named "ntuser" instead of using "sambaSamAccount", which is the correct objectclass for Samba 3.0 integration. Can this be changed? Also, Fedora Directory Server has a plugin for Password Modify (LDAP_EXTOP_PASSMOD) which requires the invoker to always supply the original password along the new password. This causes problems when trying to use password synchronization between Samba and FDS, since Samba can''t supply the original password. Can this be changed? It seems to me the only way of fixing this is by modifying the source file sources/ldapserver/ldap/servers/slapd/passwd_extop.c, but the building process seems overwhelming for me to try. Any ideas? Thanks!
Felipe Alfaro Solana wrote:>Hello, > >I have seen Fedora Directory Server console has support for "NT User" >attributes when creating a new user in the directory. However, it >seems the enabling the "NT User" capability uses an objectclass named >"ntuser" instead of using "sambaSamAccount", which is the correct >objectclass for Samba 3.0 integration. Can this be changed? > >NT user is for Windows synchronization (AD sync) - this is different than samba support. We are investigating adding support for samba to the console for a future release.>Also, Fedora Directory Server has a plugin for Password Modify >(LDAP_EXTOP_PASSMOD) which requires the invoker to always supply the >original password along the new password. This causes problems when >trying to use password synchronization between Samba and FDS, since >Samba can''t supply the original password. Can this be changed? It >seems to me the only way of fixing this is by modifying the source >file sources/ldapserver/ldap/servers/slapd/passwd_extop.c, but the >building process seems overwhelming for me to try. > >This is probably a bug in the server. I can''t remember if the IETF password modify draft says that the original password can be omitted (the server has it anyway, from the BIND operation), but other password modify extop clients expect to be able to only pass in the new password.>Any ideas? >Thanks! > >-- >Fedora-directory-users mailing list >Fedora-directory-users@redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-users > >
> >Samba can''t supply the original password. Can this be changed? It > >seems to me the only way of fixing this is by modifying the source > >file sources/ldapserver/ldap/servers/slapd/passwd_extop.c, but the > >building process seems overwhelming for me to try. > > > > > This is probably a bug in the server. I can''t remember if the IETF > password modify draft says that the original password can be omitted > (the server has it anyway, from the BIND operation), but other password > modify extop clients expect to be able to only pass in the new > password.I would say it''s a bug, indeed (from the RFC3602): --- BEGIN --- 2. Password Modify Request and Response The Password Modify operation is an LDAPv3 Extended Operation [RFC2251, Section 4.12] and is identified by the OBJECT IDENTIFIER passwdModifyOID. This section details the syntax of the protocol request and response. passwdModifyOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.1 PasswdModifyRequestValue ::= SEQUENCE { userIdentity [0] OCTET STRING OPTIONAL oldPasswd [1] OCTET STRING OPTIONAL newPasswd [2] OCTET STRING OPTIONAL } ... The userIdentity field, if present, SHALL contain an octet string representation of the user associated with the request. This string may or may not be an LDAPDN [RFC2253]. If no userIdentity field is present, the request acts up upon the password of the user currently associated with the LDAP session. The oldPasswd field, if present, SHALL contain the user''s current password. ... --- END --- As you can see, the oldPasswd is an OPTIONAL ASN.1 attribute. Should I submit a bug report for this? Thanks!
Felipe Alfaro Solana wrote:>>>Samba can''t supply the original password. Can this be changed? It >>>seems to me the only way of fixing this is by modifying the source >>>file sources/ldapserver/ldap/servers/slapd/passwd_extop.c, but the >>>building process seems overwhelming for me to try. >>> >>> >>> >>> >>This is probably a bug in the server. I can''t remember if the IETF >>password modify draft says that the original password can be omitted >>(the server has it anyway, from the BIND operation), but other password >>modify extop clients expect to be able to only pass in the new >>password. >> >> > >I would say it''s a bug, indeed (from the RFC3602): > >--- BEGIN --- >2. Password Modify Request and Response > > The Password Modify operation is an LDAPv3 Extended Operation > [RFC2251, Section 4.12] and is identified by the OBJECT IDENTIFIER > passwdModifyOID. This section details the syntax of the protocol > request and response. > > passwdModifyOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.1 > > PasswdModifyRequestValue ::= SEQUENCE { > userIdentity [0] OCTET STRING OPTIONAL > oldPasswd [1] OCTET STRING OPTIONAL > newPasswd [2] OCTET STRING OPTIONAL } >... >The userIdentity field, if present, SHALL contain an octet string > representation of the user associated with the request. This string > may or may not be an LDAPDN [RFC2253]. If no userIdentity field is > present, the request acts up upon the password of the user currently > associated with the LDAP session. > > The oldPasswd field, if present, SHALL contain the user''s current > password. >... >--- END --- > >As you can see, the oldPasswd is an OPTIONAL ASN.1 attribute. Should I >submit a bug report for this? > >Yes, please.>Thanks! > >-- >Fedora-directory-users mailing list >Fedora-directory-users@redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-users > >