search

jamf / JamfMigrator

A tool to migrate data granularly between Jamf Pro servers
MIT License
140 stars 10 forks source link

Error When Migrating Policies with LDAP Group Limitations #53

Closed sjgrall closed 4 years ago

sjgrall commented 4 years ago

When attempting to migrate policies with LDAP group(s) set on the Limitations tab of the Jamf Pro policy, the following type of error is returned, and the policy is not migrated:

20200513_075250 [CreateEndpoints] [policies] Security - Reissue FileVault Recovery Key - Failed (409). Create error: Problem matching limit_to_users user group .

All other policies (policies without LDAP group limitations) were migrated. This error appears to have been returned for every single policy whereby we had set an LDAP group limitation.

BIG-RAT commented 4 years ago

Thanks for the heads up @sjgrall. Issue should be resolved in v5.2.5

sjgrall commented 4 years ago

It's still not working, unfortunately. I get a different response now: 20200513_192228 [CreateEndpoints] [policies] Security - Reissue FileVault Recovery Key - Failed (409). Create error: Problem matching limitation user group .

BIG-RAT commented 4 years ago

I trust the LDAP group(s) appear when tested in the LDAP config? Could you post what you have (raw XML) for the scope of one of the failing policies? My testing with the following had no issues.

<scope>
    <all_computers>false</all_computers>
    <computers>
        <computer>
            <id>54</id>
            <name>dev-rmbp</name>
            <udid>689349F2-3D36-1B66-3EFA-BBAED37066F7</udid>
        </computer>
    </computers>
    <computer_groups>
        <computer_group>
            <id>182</id>
            <name>East</name>
        </computer_group>
    </computer_groups>
    <buildings>
        <building>
            <id>1</id>
            <name>Corporate</name>
        </building>
    </buildings>
    <departments></departments>
    <limit_to_users>
        <user_groups>
            <user_group>PowerUsers</user_group>
        </user_groups>
    </limit_to_users>
    <limitations>
        <users></users>
        <user_groups>
            <user_group>
                <id>16536</id>
                <name>PowerUsers</name>
            </user_group>
        </user_groups>
        <network_segments></network_segments>
        <ibeacons></ibeacons>
    </limitations>
    <exclusions>
        <computers></computers>
        <computer_groups></computer_groups>
        <buildings></buildings>
        <departments></departments>
        <users>
            <user>
                <name>Joe90</name>
            </user>
        </users>
        <user_groups>
            <user_group>
                <id>16520</id>
                <name>Remote</name>
            </user_group>
        </user_groups>
        <network_segments></network_segments>
        <ibeacons></ibeacons>
    </exclusions>
</scope>
sjgrall commented 4 years ago

Yes, LDAP groups appear if tested. How do I generate that XML output?

BIG-RAT commented 4 years ago

Click the preferences button, export tab, then select the desired export options. Raw is the source XML as it is pulled from the server. Trimmed is the XML that is posted to the destination server. And of course be sure to include the scope.

export
sjgrall commented 4 years ago

Here's a RAW XML example for scope, as you requested: (updated; I had posted the trimmed before, in error).

<scope>
    <all_computers>true</all_computers>
    <computers></computers>
    <computer_groups></computer_groups>
    <buildings></buildings>
    <departments></departments>
    <limit_to_users>
        <user_groups>
            <user_group>NCI CBIIT Desktop Platform Management</user_group>
            <user_group>NCI CBIIT Desktop Technicians</user_group>
            <user_group>NCI DEA Secondary Administrators</user_group>
        </user_groups>
    </limit_to_users>
    <limitations>
        <users></users>
        <user_groups>
            <user_group>
                <id>916110</id>
                <name>NCI CBIIT Desktop Platform Management</name>
            </user_group>
            <user_group>
                <id>99714</id>
                <name>NCI CBIIT Desktop Technicians</name>
            </user_group>
            <user_group>
                <id>94531</id>
                <name>NCI DEA Secondary Administrators</name>
            </user_group>
        </user_groups>
        <network_segments></network_segments>
        <ibeacons></ibeacons>
    </limitations>
    <exclusions>
        <computers></computers>
        <computer_groups></computer_groups>
        <buildings></buildings>
        <departments></departments>
        <users></users>
        <user_groups></user_groups>
        <network_segments></network_segments>
        <ibeacons></ibeacons>
    </exclusions>
</scope>
BIG-RAT commented 4 years ago

Thanks @sjgrall - I created the same groups (in case there was something about the name) and scope. Migration worked worked for me. Here is where we might need the waders: If you could, put your Jamf server into debug mode and then try to migrate again. In the debug log search for LDAP or part of a group name. Should see something like the following:

2020-05-15 09:55:45,138 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Search LDAPServer [ID=4, Name=lab.private] for group NCI CBIIT Desktop Technicians with wildcards true
2020-05-15 09:55:45,139 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Search Filter: (&(&(objectClass=top)(objectClass=group))(name=*NCI CBIIT Desktop Technicians*))
2020-05-15 09:55:45,139 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Open LDAP Connection to lab.private
2020-05-15 09:55:45,161 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Executing LDAP search on base 'DC=lab,DC=private' with scope 2
2020-05-15 09:55:45,170 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - CN=NCI CBIIT Desktop Technicians,OU=Remote User Test,OU=Another OU,OU=Test,OU=Corp: null:null:{name=name: NCI CBIIT Desktop Technicians, instancetype=instanceType: 4, grouptype=groupType: -2147483644, objectsid=objectSid: [B@779b8335, samaccounttype=sAMAccountType: 536870912, usncreated=uSNCreated: 2796634, usnchanged=uSNChanged: 2796634, objectclass=objectClass: top, group, distinguishedname=distinguishedName: CN=NCI CBIIT Desktop Technicians,OU=Remote User Test,OU=Another OU,OU=Test,OU=Corp,DC=lab,DC=private, objectcategory=objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=lab,DC=private, samaccountname=sAMAccountName: NCI CBIIT Desktop Technicians, objectguid=objectGUID: [B@77994e78, cn=cn: NCI CBIIT Desktop Technicians, whencreated=whenCreated: 20200515143409.0Z, whenchanged=whenChanged: 20200515143409.0Z, dscorepropagationdata=dSCorePropagationData: 16010101000000.0Z}
2020-05-15 09:55:45,170 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - LDAP parse Group
2020-05-15 09:55:45,171 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - LDAP parse Group done
2020-05-15 09:55:45,171 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - PartialResultException was handled.
2020-05-15 09:55:45,171 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Finished LDAP lookup
2020-05-15 09:55:45,172 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Closing LDAP Connect
2020-05-15 09:55:45,172 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Search LDAPServer [ID=4, Name=lab.private] for group NCI DEA Secondary Administrators with wildcards true
2020-05-15 09:55:45,172 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Search Filter: (&(&(objectClass=top)(objectClass=group))(name=*NCI DEA Secondary Administrators*))
2020-05-15 09:55:45,172 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Open LDAP Connection to lab.private
2020-05-15 09:55:45,173 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Executing LDAP search on base 'DC=lab,DC=private' with scope 2
2020-05-15 09:55:45,177 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - PartialResultException was handled.
2020-05-15 09:55:45,177 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Finished LDAP lookup
2020-05-15 09:55:45,178 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - Closing LDAP Connect

Here, you see it found the group NCI CBIIT Desktop Technicians (timestamp: 2020-05-15 09:55:45,170) but did not find the group NCI DEA Secondary Administrators (I'd deleted this group) and gave up on any further lookups. I'm curious if you see any successful lookups. Ideally all should return something like

2020-05-15 09:55:45,170 [DEBUG] [Thread-176 ] [DefaultLDAPLookupService ] - CN=NCI CBIIT Desktop Technicians,OU=Remote User Test,OU=Another OU,OU=Test,OU=Corp: null:null:{name=name: NCI CBIIT Desktop Technicians, instancetype=instanceType: 4, grouptype=groupType: -2147483644, objectsid=objectSid: [B@779b8335, samaccounttype=sAMAccountType: 536870912, usncreated=uSNCreated: 2796634, usnchanged=uSNChanged: 2796634, objectclass=objectClass: top, group, ...
sjgrall commented 4 years ago

Yes, the lookups are successful on the destination server, and it returns all group members for each of those groups. However, because of the sensitive nature of the group membership, I cannot send you the exact output from the debug log.

sjgrall commented 4 years ago

Update: The remaining issue I've had was caused by the presence of two LDAP server configs with overlapping matching user groups. Our institution's AD is unique in its structure, and some user groups are accessible from two different OU structures on the same AD LDAP system, whereas others are not. I removed the secondary LDAP server config, which isn't needed on our dev server, and it worked around the issue.

BIG-RAT commented 4 years ago

Good to hear. I'll stop scratching my head one this one - thanks!