On 06/03/2016 11:25 AM, Job Cacka wrote:
On 06/02/2016 07:34 PM, Job Cacka wrote:
Right, the problem was that you added "[-x]" which was treated as a
requested attribute. This obviously is not a real attribute so no other
attributes were returned. It was also breaking the filter for some reason.
[02/Jun/2016:15:45:04 -0700] conn=36851 op=1 SRCH base="dc=domain,dc=com"
scope=2 filter="(objectClass=*)" attrs="[-x] uid=*"
This is the ldapsearch you were probably trying to do:
ldapsearch -H ldaps://ds1.domain.com -D "cn=directory manager" -w
"pass"
-xLLL -b "dc=domain,dc=com" uid=test2015
Thanks for your help! Now that I see the results I expected all of the things that I was reading about ldapadd and ldapmodify make more sense. Also, they seem possible. How do you change what you can't see in a live system? Not very effectively.
Anyway, you could have just removed the brackets around the -x and it
would have solved your problems. Glad you got it working.
Mark
It appears there are two "built-in" users in 389 DS.
"uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot"
"cn=directory manager"
Well there is always the Directory Manager account that is built into
the server(its not in a database). The "uid=admin,..." account is in
the database for the "o=netscaperoot" suffix.
But you probably have another database suffix where you would want to
store your users: This is typically something like: dc=your_domain,dc=com
or at least we have created users with two different users.
My main problem is that the smbldap-tools command we use to create a windows, unix, and email user stopped working.
I am not familiar with this tool.
If I run it I get:
# createusr test06032016a
Can't call method "get_value" on an undefined value at /usr/local/sbin/smbldap-useradd line 271.
/usr/local/sbin/smbldap-passwd: user test06032016a doesn't exist
User does not exist: test06032016a
The script is:
# cat /usr/local/sbin/createusr
:
/usr/local/sbin/smbldap-useradd -a -m -c "$1" $1
/usr/local/sbin/smbldap-passwd $1
/usr/local/sbin/smbldap-groupmod -m $1 "Domain Users"
exit
It breaks at line 271:
{
# as grouprid we use the value of the sambaSID attribute for
# group of gidNumber=$userGidNumber
$group_entry = read_group_entry_gid($userGidNumber);
$userGroupSID = $group_entry->get_value('sambaSID'); ## It fails on this line
unless ($userGroupSID) {
print "Error: SID not set for unix group $userGidNumber\n";
print "check if your unix group is mapped to an NT group\n";
exit(7);
}
$userRid = user_next_rid($userUidNumber);
$user_sid = "$config{SID}-$userRid";
}
Line 271 is the "unless ($userGroupSID) {"
I would like to find out how to troubleshoot what is happening in perl on line 270, because I believe it is not getting the "sambaSID". Then I should be able to figure out why the createusr script is failing.
Well I can only address this form the Directory Server standpoint... So
on the DS side you should check the access log to see if the tool is
actually hitting the server, and how its failing. Can you provide the
access log output when you run those commands? Note there is access log
buffering (30 seconds). So run the commands, wait 30 seconds, and
provide the access log output (after you remove any sensitive data).
Thanks,
Mark
This is one reason I was asking about user permissions. Could some users not have access to the "sambaSID" and if so what did we do to change it? Or has the communication settings changed somehow?
Thanks,
Job
--
389-users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
--
389-users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
